スナップショットの依存関係
ビルド (たとえば、ビルド B) のスナップショット依存関係を別のビルド (ビルド A) のソースに設定することで、ビルド B がビルド A の実行と終了の後にのみ開始されることを保証できます。ビルド A は依存関係ビルドと呼ばれ、ビルド B は依存ビルドと呼ばれます。
ビルド設定 | 依存関係ページには、構成された依存関係が表示されます。このページのスナップショットの依存関係セクションでは、ビルドチェーンとその構成をプレビューできます。プレビューにはチェーンのビルドが表示されます。自動トリガーが構成されたビルドには、
アイコンが表示されます。
スナップショットの依存関係には、次のオプションがあります。
オプション | 説明 |
|---|---|
依存先 | 依存するビルド構成を指定します。 この例では、現在のビルド B の依存関係としてビルド A を選択します。 |
リビジョン同期を強制する | このオプションが有効になっている場合 (デフォルト)、スナップショット依存関係によってリンクされているチェーン内のすべてのビルドに対して、TeamCity は同じソースのスナップショット (同じ VCS ルートの同じリビジョンなど) を使用します。これは、ビルドを正常に行うためにソースの同じ状態を使用する必要がある構成に推奨される設定です。 スナップショット依存関係に対してこのオプションを無効にすると、依存関係ビルドが現在のビルド構成に昇格されたときに、現在のビルド構成のビルドでは、昇格された依存関係に対応するリビジョンではなく、ソースの最新のリビジョンが使用されます。これは、ビルドに厳密なソース依存関係がない場合に便利です (たとえば、パッケージおよびデプロイ手順の場合など)。 この例では、ビルド B のスナップショット依存関係でこのオプションが無効になっている場合、動作は次のようになります。ビルド A はリビジョン 1.2 で起動し、終了後にビルド B に昇格します。TeamCity は、B を起動した時点でビルド B の最新リビジョン(1.3 とします)を見つけます . ソースのスナップショットルールは、オプションが有効になっているスナップショット依存関係を介してリンクされたビルド (チェーン) の部分にのみ適用されることに注意してください。 |
適切なものがあれば、新しいビルドを実行しないでください | このオプションを有効にすると、適切なソースのリビジョンを持つ別の実行中または完了した依存関係ビルドがすでに存在する場合、TeamCity は新しい依存関係ビルドを実行しません。適切なビルドも参照してください。 |
適切なビルドから成功したビルドのみを使用する | 新しくトリガーされたビルドでは、依存関係として正常に完了した適切なビルドのみが使用されます。最新の完了した適切なビルドが失敗した場合は、再実行されます。 |
同じエージェントでビルドを実行する | 有効で B スナップショット -A に依存する場合、各ビルド B は、同じビルドチェーンのビルド A が実行されたのと同じエージェントで実行されます。 |
依存関係の失敗 / 開始に失敗 / 依存関係のキャンセル | 依存関係が失敗した場合は、次のいずれかのオプションを選択して依存関係のあるビルドのステータスを管理できます。
|
適切なビルド
スナップショット依存関係に関して、適切なビルドとは、ビルドチェーン内のキューに入れられた依存関係ビルドの代わりに使用できるビルドです。つまり、ビルドチェーンの一部であるキューに入れられたビルドは削除でき、それに依存するビルドは、キューに入れられた、実行中の、すでに完了した別の「適切な」ビルドに依存させることができます。この動作は、対応するスナップショット依存関係の「適切なものがあれば、新しいビルドを実行しないでください」オプションが有効になっている場合にのみ機能します。
ビルドが「適切」であるとみなされるには、次のすべての条件を満たしている必要があります。
同じブランチまたはデフォルトのブランチに属している必要があります。
処理中のキュービルドチェーン全体として同じ情報源のスナップショットを使用する必要があります。ビルド構成の VCS 設定が同じ場合、これは同じ情報源の改訂を意味します。VCS 設定が異なる場合 (VCS ルートまたはチェックアウトルール)、これはある時点で同時に取得されたリビジョンを意味します。
成功する必要があります (「適切なビルドから成功したビルドのみを使用する」スナップショット依存関係オプションが有効になっている場合)。
それは個人的なビルドではなく、通常のビルドである必要があります。
reverse.dep.パラメーター(関連機能要求: TW-23700(英語))を介して設定されたパラメーターを含め、カスタマイズされたパラメーターがあってはなりません。元のビルドは、依存関係ビルド構成の「再ビルド」アクションによってトリガーされてはなりません。
有効なリビジョン計算を妨げる VCS 設定があってはなりません。詳細については、こちらを参照してください。
「適切なものがあれば、新しいビルドを実行しないでください」オプションが無効になっている現在のビルド構成スナップショットに依存する他のビルド構成スナップショットはありません。
実行中のビルドは「ハング」していません。
ビルド構成の設定は、ビルド以降変更されていません(つまり、ビルドは現在のビルド構成設定で実行されました)。これには、ビルド構成のすべての親プロジェクトのパラメーターへの変更も含まれません。隠されたビルドのアーティファクトの
.teamcity/settings/digest.txtファイルを比較することで、複数のビルド間で設定が変更されたかどうかを確認できます。スナップショットの依存関係に加えてアーティファクトの依存関係も存在する場合、適切なビルドにはアーティファクトが含まれている必要があります。それ以外の場合は、公開されたアーティファクトを含まないビルドと、クリーンアップ中にアーティファクトが削除されたビルドのどちらも同様に適しています。
すべての依存関係ビルド (現在のビルドが依存するビルド) は「適切」であり、適切にマージされます。
ビルドの再利用を無効にする VCS 設定
VCS ルートの一部の設定では、ビルドの再利用を効果的に無効にすることができます。これらの設定は次のとおりです。
Subversion: チェックアウトしますが、変更を無視するモード
CVS: タグによるチェックアウトモード
Perforce: ストリームまたはクライアント接続設定、またはラベルがチェックアウトするラベル / 改訂として指定されている
Starteam: チェックアウトモードオプションがラベルまたはプロモーションの日付を表示するように設定されました
アップストリームチェーンビルドでの並列テスト
常に新しいビルドを実行するの動作 ( スナップショット依存関係の 適切なものがあれば、新しいビルドを実行しないでください設定が無効) は、メイン構成ビルドにのみ影響します。並列テスト機能の使用時に動的に生成される仮想ビルド構成では、以前の結果が再利用される可能性があります。新しいリポジトリコミットが検出されなかった場合、以前に失敗したテストバッチのみが新しいビルドを実行し、成功したバッチは再利用されます。
下の図では、「Composite Conf」構成は「Maven App」構成に依存しています。後者は、2 つの並列バッチでテストを実行します。メインの「Maven app」ビルド #18 は新たにトリガーされますが、動的に生成された「Maven app 1」構成は、以前の成功したビルド (#12) を再利用することに注意してください。

TeamCity にすべての仮想構成ビルドを強制的に再実行させることができます。この場合、新しいリポジトリコミットが見つからなくても、個々のテストバッチはすべて新たに実行されます。

これを行うには、並列テスト機能を含む構成に teamcity.internal.splitBuild.dependency.takeStartedBuildWithSameRevisions=false パラメーターを追加します。
この動作をサーバー上のすべての構成に適用するには、このパラメーターを内部プロパティリストに追加します。
関連ページ:
プロジェクト管理者ガイド
このセクションでは、プロジェクト管理に焦点を当てます。TeamCity プロジェクトとビルド構成の作成、ビルドステップの設定、依存関係チェーンの構成などについて説明します。基本的な TeamCity ワークフロー:次のダイアグラムは、基本的な TeamCity ワークフローを示しています。TeamCity サーバーはリポジトリの変更を検出しました。サーバーはこの変更をデータベースに書き込みます。ビルド構成に添付されたトリガーは、データベース内の関連する変更を検出し、ビルドを開始します。トリガー...
ビルドチェーン
ビルドチェーンは、スナップショット依存関係によって相互接続された一連のビルドです。ビルドチェーンは「パイプライン」と呼ばれることもあります。リビジョン同期が有効になっているスナップショット依存関係にリンクされたビルドチェーンの各部分は、ソースの同じスナップショットを使用します。一般的なユースケース:ビルドチェーンを指定する最も一般的な使用例は、プロジェクトの同じテストスイートを異なるプラットフォームで実行することです。例: リリースビルドの前に、さまざまなプラットフォームと環境でテストが正しく実...
コンポジットビルド構成
コンポジットビルド構成は、複数の通常のビルド構成をトリガーし、結果を 1 か所で追跡するように設計された「ステップレス」構成です。重要なポイント:複合構成では、実際の構築ルーチンは実行されません。複合構成では、依存関係からすべての情報が集約され、一元的な方法で表示されます。複合ビルドはビルドキュースロットを占有せず、エージェントを実行する必要もありません。ビルド構成タイプを切り替えるには、「構成設定 | 一般」タブに移動します。サンプル:このチュートリアルでは、複数のビルド構成を作成し、1...
パーソナルビルドの実行
個人ビルドは、通常、バージョン管理にまだコミットされていない変更を使用する共通ビルドシーケンスからのビルドです。個人ビルドは通常、サポートされている IDE の 1 つからリモート実行プロシージャを介して開始されます。カスタムビルドを実行するダイアログから個人ビルドを開始し、変更を加えたパッチをサーバーに直接アップロードすることもできます。個人ビルドには対応するアイコンが付いており、ビルドを開始したユーザーのみに表示されます。他の TeamCity ユーザーの個人ビルドを表示するには、ユーザープロ...
アーティファクトのビルド
アーティファクトのビルドはビルドによって生成されたファイルです。通常、これらにはディストリビューションパッケージ、WAR ファイル、レポート、ログファイルなどが含まれます。ビルド構成を作成するときは、一般設定を構成するページでビルドのアーティファクトへのパスを指定します。アーティファクトストレージ:TeamCity には、統合された軽量ビルドアーティファクトリポジトリが含まれています。アーティファクトは、サーバーアクセス可能ファイルシステムまたは外部ストレージに保存されます。ビルドが終了すると...
TeamCity データのクリーンアップ
TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。特定のプロジェクトに関連するクリーンアップルールはプロジェクト設定で設定されます | クリーンアップルール。これらのルールは、どのデータをクリーンアップし、どのデータを保持するかを定義します。これらは、プロジェクトまた...