TeamCity 2019.2 の新機能改行文字列 value? Need no newline.
新しい柔軟なクリーンアップルール
自動ビルドクリーンアップは、初期バージョンから TeamCity に搭載されています。 古い、不要なビルドデータを簡単に削除できます。 提供されたカスタマイズオプションは非常に簡単に構成できますが、最も一般的なケースのみを対象としており、微調整はできません。
このリリースでは、クリーンアッププロセスを柔軟に制御するためのオプションをさらに導入しています。 プロジェクトまたはビルド構成の既存の「基本ルール 」に加えて、クリーンアップ中に保持するビルドとデータを指定するための複数の「保持ルール 」を作成できるようになりました。 保持ルールはよりきめ細かく、特定のタグ (たとえば、 リリース) を持つビルドや特定のブランチ内のすべてのビルドを保持するなどのケースをカバーできます。 新しい保持ルールを使用するには、さまざまな種類のビルドとそのデータをよりよく理解する必要がありますが、柔軟性も向上します。
プロジェクト設定 の クリーンアップルール セクションを使用すると、現在のプロジェクトとそのサブプロジェクトとビルド構成の基本ルールと保持ルールを管理できます。
キープルールを追加するときに、次を指定できます。
保持するビルドデータ: 履歴、アーティファクト、ログ、統計、すべて。
ビルド範囲: ルールの影響を受ける時間間隔または最後のビルドの数。
必要に応じて、ビルドを 状況、 タグ、 ブランチ で フィルター できます。 ビルドを 個人用 または 非個人用 のみに制限するかどうかを選択します。
また、ルールを一致する各ブランチに個別に適用するか、選択したブランチ内のすべてのビルドに単一の設定として適用するかを選択できます。
キープルールの例:
さらに読む 掃除
メトリクスレポート
TeamCity は Prometheus 互換のサーバーメトリクスを提供するようになりました。このメトリクスは 診断 | メトリクス タブに表示され、 app/metrics API エンドポイントから利用できます。
メトリクスにアクセスするには、TeamCity ユーザーアカウントに「使用統計を表示 」権限が割り当てられていることを確認してください。
メトリクスには以下が含まれます。
CPU、メモリ、システムの負荷
ビルドキューの処理にかかった時間
アクティブなユーザーセッションの数
およびその他
完全なリストは https://<teamcity-サーバー-ホスト>/アプリ/メトリクス盾アプリ/REST/クラウド/プロファイルシールドアプリ/REST/クラウド/インスタンスଷアプリ/REST/クラウド/画像w.diffgit diff .diff git diff で入手できます。
一部のメトリクスは実験的ですが、エンドポイント URL に ?experimental=true クエリ文字列を追加するか、 メトリクス タブで「実験的指標を表示 」オプションを有効にすることで、すでにそれらにアクセスできます。
メトリクスを収集するには、Prometheus データベース、または Telegraf & InfluxDB の組み合わせを使用することをお勧めします。 メトリクスを視覚的に表現するには、 グラファナ(英語)または他の同様のソリューションを使用できます。
Grafana で表現された TeamCity メトリクスの例:
ビルドランナースクリプトでのコードハイライト
次のビルドランナーのスクリプトに、自動コードハイライトと行番号を追加しました: コマンドライン、 Ant、 PowerShell、 Docker、 NAnt、 Rake 、および Amazon EC2 イメージの構成。
読みやすくするために、入力フォームの横にある 
をクリックして、コードにソフトラップを適用できるようになりました。
TeamCity での Dockerfile ハイライトの例:
EC2 起動テンプレートのサポート
TeamCity はクラウドインスタンス向けに Amazon EC2 起動テンプレートをサポートするようになりました。 多くの EC2 ユーザーは起動テンプレートを高く評価しています。一度定義した起動仕様をすべての新しいインスタンスで再利用できるため、新しいインスタンスがリクエストされるたびに起動設定を記述する必要がなくなります。
クラウドプロファイルが Amazon サーバーに接続されている場合、TeamCity はこのサーバーで利用可能な起動テンプレートを自動的に検出します。 テンプレートをイメージの ソースとして選択してバージョンを指定するだけで、TeamCity はテンプレートパラメーターに基づいてインスタンスをリクエストします。
詳しくは Amazon EC2 向け TeamCity の設定を参照してください。
TeamCity 起動時のバックアップ復元
TeamCity サーバーインスタンスを初めて起動し、以前の TeamCity インストールのバックアップデータを復元したい場合、起動画面の UI から直接バックアップを復元できるようになりました。
詳しくは バックアップからの TeamCity データの復元を参照してください。
統合 diff でのパーソナルビルドの実行
TeamCity UI または REST API 経由でアップロードされた diff パッチに基づいて、ローカル変更を含むパーソナルビルドを実行できるようになりました。
以前は、ローカル変更に基づくパーソナルビルドを実行するには、TeamCity サーバーを一部の サポート対象 IDEと統合する必要がありました。 これで、パッチを統一された形式 (たとえば、IntelliJ IDEA または git diff コマンドを使用) で .diff ファイルとして保存し、サーバーに直接アップロードできるようになりました。
パーソナルビルドのこの機能の詳細を参照してください。
これは実験的な機能であることに注意してください。 TeamCity は、Git と IntelliJ IDEA によって生成された unidiff ファイルの安定した解析を提供します。 非バイナリファイルでのバイナリ変更はサポートされていません。
クラウドプロファイル向け REST API の拡張
TeamCity REST API は、TeamCity UI で提供されるものと同じクラウド統合の詳細を公開する .../app/rest/cloud/profiles、 .../app/rest/cloud/images、 .../app/rest/cloud/instances エンドポイントを提供するようになりました。
プルリクエスト用の定義済みビルドパラメーター
プルリクエストに関する重要な情報を公開するために、いくつかの定義済みビルドパラメーターを追加したため、ビルド構成の設定またはビルドスクリプトで使用できます。
クロスプラットフォーム dotCover のサポート
TeamCity は、クロスプラットフォームの JetBrains dotCover バージョン 2019.2.3+ をサポートすることで、Linux と macOS 上の .NET Core プロジェクトのコードカバレッジを収集できるようになりました。
Windows 向け dotCover 2019.2.3 は TeamCity にバンドルされています。 Windows 以外のプラットフォームでコードカバレッジを収集する必要がある場合は、 管理 | ツール でクロスプラットフォーム dotCover ツールを追加し、 .NET CLI ビルドステップで dotCover カバレッジを有効にします。 Windows でもクロスプラットフォーム dotCover を使用する場合は、エージェントに .NET フレームワーク SDK 4.6.1+ がインストールされていることを確認してください。
また、 コンテナーラッパー 拡張を使用して、Docker コンテナー内の dotCover でコードカバレッジ分析を実行できます。
マルチノードセットアップの更新
セカンダリノードでのユーザーレベルのアクション
以前のバージョンの TeamCity では、セカンダリノードは読み取り専用インターフェースを提供していました。 ビルドをキューに追加したり、ビルドをタグ付け / 固定したり、その他のユーザーレベルのアクションを実行したりすることはできませんでした。 このリリースでは、変更されます。 これで、セカンダリノードに責任が与えられた場合（つまり、読み取り専用サーバーとして機能しない場合）、ユーザーのビルドアクションが有効になります。 現在、サポートされているユーザーレベルのアクションは次のとおりです。
カスタムまたは個人のビルドを含むビルドのトリガー
ビルドを停止する
ビルドのピン留め / タグ付け / コメント
ビルドを削除する
調査の割り当てとミュートのビルドの問題とテスト
ビルドを成功 / 失敗としてマークする
ソースのマージとソースのラベル付けアクション
トラッカー TW-62749(英語) でサポートされているアクションの完全なリストを参照してください。
管理者レベルのアクションは、セカンダリノードではまだ使用できません。 サーバー構成を変更する必要がある場合は、メインサーバーを使用します。
エージェントでのサーバー側パッチのダウンロードを最適化
このリリース以降、エージェントは、以前のようにメインサーバーからだけでなく、セカンダリノードからサーバー側パッチをダウンロードできます。
サーバー側パッチは、エージェントがエージェントマシン上で VCS クライアント実行可能ファイル (Git や Perforce など) を見つけられない場合によく使用されます。 この場合、エージェントはサーバーに VCS の変更を含むパッチを作成し、それをエージェントに送信するように要求します。 ここで、「VCS リポジトリのポーリング 」および「ビルドによって生成されたデータの処理 」の責任をセカンダリノードに割り当てると、エージェントはこのノードからもパッチを要求できるようになり、メインサーバーの負荷が大幅に軽減されます。
DSL ベースのプロジェクトの更新
TeamCity Kotlin DSL には次の更新があります:
実験的 UI の新機能
TeamCity 2019.2 では、再設計された ビルド詳細ページと エージェントページ、およびその他の 実験的機能が導入されています。
実験的なビルド詳細ページ
ビルドの詳細を表示する方法を再考するために、 ビルド詳細 ページを再設計して、視覚化を改善し、サイドバーを介して他のすべてのプロジェクトにすばやくアクセスできるようにしました。
現在のビルドページを移動せずに、以前のすべてのビルドとその詳細を即座にプレビューできます。
視覚化されたビルドタイムラインは、各ステージの期間を反映し、ビルドの問題を示します。
ビルドステージをクリックして、ビルドログの対応する行を開きます。 新しい UI では、長いログであっても、ダウンロードする必要がなく、プレビューに直接表示できます。
ビルドタイムラインとビルドログ以外に、 概要 タブからビルドの問題、テスト、変更、依存関係にすばやくアクセスできます。 対応するタブも更新され、新しい機能が提供されるようになりました。
変更 タブには、ビルドの変更に関する詳細情報が表示されます。 ユーザー変更とアーティファクト変更を個別に閲覧でき、必要に応じてビルド設定の変更も表示できます。 任意の変更をクリックすると、その詳細をプレビューできます。
テスト タブでは、失敗したテスト、無視されたテスト、成功したテストをすばやく切り替えられます。 テストをクリックすると詳細を表示し、調査を割り当てることができます。
依存関係 タブには、ビルドの依存関係を表示する 3 つの代替モードがあります。
実験エージェントのページ
実験的な エージェント ページは、多数のエージェントに対してより高速にロードされ、エージェントの詳細をすばやく切り替えることができます。 サイドバーを使用して、エージェントプール階層を参照し、名前でエージェントとプールを検索できます。 レポート セクションは、すべてのプールで実行中、アイドル、切断されたエージェントに関する統計を提供します。
実験的 UI のその他の新機能
二つのビルドの比較
ビルドの比較機能を使用すると、同じ構成から二つのビルドを選択し、パラメーター、リビジョン、統計、テストに関する情報を並べて確認できます。 これにより監視が簡単になり、複数のユーザーがビルドを管理および監視する場合に特に役立ちます。 たとえば、ビルドのプロジェクトコードに変更がないのに明らかな理由なく失敗する場合は、このビルドを最後に成功したビルドと比較し、その差分を分析して、失敗の最も可能性の高い原因を見つけることができます。
ビルドを別のビルドと比較するには、このビルドの アクション メニューを開き、 比較対象 をクリックして、比較対象のビルドを選択します。ビルドリスト内の展開されたビルドプレビュー
TeamCity では、ビルドのリストで最も重要なビルド結果を直接プレビューできるようになりました。 ビルド構成ホーム ページで、リストのビルド行をクリックして詳細を表示します。お気に入りプロジェクトセクション
お気に入りのプロジェクトにすばやくアクセスできる プロジェクト セクションを移行しました。再設計された変更ポップアップ
ビルドの変更は時系列でソートされ、コードの変更とアーティファクトの依存関係の変更によってグループ化されるようになりました。 作成者によって変更をフィルターし、ビルド構成設定で行われた変更の表示を切り替えることもできます。ビルドのキュー登録理由に関する情報
ビルドが長時間キューにとどまっている場合、 トレンド またはビルドリストでビルドをプレビューするときに「順番待ち 」ラベルをクリックすると、遅延の理由を確認できます。
その他の改善
アーティファクトの依存関係、再試行トリガー、プルリクエストビルド機能に ブランチフィルターが追加されました。
Dockerfile 変更の自動検出: Docker Compose ビルドランナーがエージェント上で Docker イメージを作成すると、そのイメージは後のビルドで使用できるようにこのエージェントに保存されます。 TeamCity は、イメージのビルドに使用された Dockerfile が変更されたことを自動的に検出し、Docker Compose ステップにこのイメージの再ビルドを強制するようになりました。
サーバー上のすべての VCS ルートの最小ポーリング間隔として、 グローバル設定 で指定された VCS 変更チェックの間隔を適用できるようになりました。 これにより、プロジェクト管理者はデフォルトよりも大きい間隔のみを設定できます。 これにより、ポーリング要求の頻度が制限され、サーバーの負荷が軽減されます。
「プロジェクトのユーザー / グループ通知ルールを変更する 」権限が有効になっているプロジェクト管理者は、プロジェクトに割り当てられたユーザーおよびユーザーグループの通知ルールを編集できます。
通常のビルドと同じように、パーソナルビルドを再実行できるようになりました。完了したビルドのコンテキストメニューを開き、「このビルドを再実行」をクリックします。
TeamCity は、
git fetchプロセスが使用するメモリ量を自動的に管理できます。
以前にTeamCity.Git.フェッチ.プロセス.最大.メモリ内部プロパティを使用して各 VCS ルートでフェッチに使用できるメモリ量を設定していた場合、このプロパティを無効にして、メモリ消費量の検出を TeamCity サーバーに委任できるようになりました。teamcity.git.fetch.process.max.memory.limitプロパティを使用して、使用可能なメモリの上限を制御できます。1 つのビルドに対して複数の SSH キーを構成できます。 ビルドが複数の外部システムまたはリポジトリで認証する必要がある場合に役立ちます。 ビルドで複数の SSH キーを使用するには:
プロジェクトレベル: これらのキーを SSH キーで指定します。
ビルド構成レベルで: キーごとに 1 つずつ、複数の SSH エージェントビルド機能を追加します。
TeamCity は、割り当てられた調査の解決と、アクティブなブランチでミュートされた問題およびテストのミュート解除に 改善されたルールを使用します。 これで、ビルドの問題 (または失敗したテスト) がすべてのアクティブなブランチで修正されるまで待機してから、ミュート解除するか、調査を解決します。
再試行ビルドトリガーは、同じリビジョンで新しいビルドをトリガーし、それをキューの先頭に配置できるようになりました。