チェーン依存関係の構成
ビルドチェーンは、 ダウンストリーム オブジェクトで 上流 オブジェクトを指す依存関係を宣言することで組み立てられます。 利用可能な設定は、ビルド構成とパイプラインのどちらでも同じです - 異なるのは UI とコードでの表現だけです。
スナップショット依存関係
スナップショット依存関係は、チェーン内の二つのビルド構成をリンクします。 用語 "snapshot" は、ソースリビジョン同期を指します: 上流ビルドと下流ビルドは同じコードスナップショットを共有し、これがチェーンを意味のあるものにする重要な保証です。
ビルド構成にスナップショット依存関係を追加するには:
構成設定を開き、 依存関係設定タブに移動します。
新しいスナップショット依存関係を追加 をクリックし、上流構成を選択します。
パイプラインの依存関係
パイプライン依存関係は、パイプラインを他のパイプラインまたはクラシックなビルド構成にリンクします。
パイプライン依存関係を追加するには:
パイプラインキャンバス領域内の任意の場所 (ジョブの外側) をクリックして、パイプラインレベルの設定を開きます。
追加 を パイプラインの依存関係 セクションでクリックします。
依存先 リストから、上流のパイプラインまたはビルド構成を選択します。

依存関係設定
次の設定は、スナップショット依存関係とパイプライン依存関係の両方に適用されます。

- 依存先
このオブジェクトを開始する前に完了している必要がある上流構成またはパイプラインを選択します。
- リビジョン同期を強制する
依存関係でリンクされた両方のオブジェクトが同じリビジョンのコードソースを使用することを TeamCity が保証するかどうかを指定します。
リビジョン同期が有効化されています: ソースの同じ状態を使用する必要があるセットアップに推奨されます。 例: 「A → B」チェーンの場合: 「A」はリビジョン 1.2 で開始され、完了すると「B」に昇格します。 ビルド "B" は、最新のリビジョンが 1.4 であっても、同じ 1.2 リビジョンで実行されます。
リビジョン同期が無効化されています: ビルドに厳密なソース依存関係がない場合(たとえば、パッケージ化とデプロイのステップを分ける場合)は、この設定を使用してください。 この場合、ダウンストリームビルドは利用可能な最新のリビジョンを使用します。 "A → B" チェーンでは、"A" はリビジョン 1.2 で開始されて "B" にプロモートされますが、"B" は最新の 1.4 リビジョンで実行されます。
この設定がビルドチェーン全体に与える影響については、 リビジョンの同期を参照してください。
- 適切なものがあれば、新しいビルドを実行しないでください
このオプションを有効化すると、適切なソースのリビジョンを持つ別のビルドがすでに実行中または完了済みの場合、TeamCity は新しいアップストリームビルドを実行しません。 再利用可能なビルドを判断するために TeamCity が使用する基準については、 適切なビルドを参照してください。
この場合、ダウンストリームビルドがトリガーされると、アップストリームビルドは引き続きキューに追加されます。 その後、チェーンの変更が収集されると、このアップストリームビルドはキューから削除され、代わりに依存関係が適切な完了済みビルドにリンクされます。
- 適切なビルドから成功したビルドのみを使用する
新しくトリガーされたビルドは、正常に完了した 適切なビルドのみを依存関係として使用します。 最新の完了済みの適切なビルドが失敗した場合は、再実行されます。
- 同じエージェントでビルドを実行する
有効化すると、下流ビルドは同じチェーン内で上流ビルドを実行した同じビルドエージェント上で実行されます。 上流ビルドがシステム状態 - インストール済みツール、環境変数、ローカルファイル - を変更し、それに下流ビルドが依存する場合に使用します。
- 依存関係が失敗した場合 / 開始に失敗した、またはキャンセルされた依存関係の場合
これらの設定では、アップストリームビルドが失敗した場合にダウンストリームビルドを実行するかどうか、また実行する場合に同じビルド問題を結果に表示するかどうかを制御できます。
ビルドを実行するが、問題を追加: ダウンストリームビルドが実行され、問題が追加されて、ステータスが失敗に変わります(問題が以前にミュートされていた場合を除く)。
ビルドを実行するが、問題を追加しない: ダウンストリームビルドが実行され、問題は追加されません。
ビルドを開始失敗としてマーク: ダウンストリームビルドは実行されず、" 起動に失敗" としてマークされます。
ビルドをキャンセル: ダウンストリームビルドは実行されず、" キャンセル済み" としてマークされます。
ビルドの再利用
チェーントリガーごとにすべての上流ビルドを実行すると、多くの場合無駄になります - 一致するビルドがすでに存在する場合、TeamCity はそれを再利用できます。 これにより、チェーンは固定されたシーケンス以上のものになります: すべてをやみくもに再実行するのではなく、TeamCity が実行する上流ビルドと以前の結果で置き換える上流ビルドを決定します。
再利用は、 適切なものがあれば、新しいビルドを実行しないでください 依存関係オプションで制御されます。 有効化すると、TeamCity は新しいビルドを開始する代わりに使用する 適切なビルドを探します。
適切なビルド
適切なビルドとは、キューに入っている上流ビルドの代わりに TeamCity が再利用できる既存のビルドです。 ビルドの再利用が有効化されている場合、TeamCity は適切なビルドを検索し、見つかった場合は依存関係をそのビルドにリンクして、キューに入っている冗長なビルドを破棄します。
次のすべての条件を満たす場合、ビルドは 適切 と見なされます:
同じブランチまたはデフォルトブランチに属しています。
キューに入っているチェーンと同じソーススナップショットを使用しています (同じリビジョン、または VCS ルートが異なる場合は同じ時点で取得されたリビジョン)。
成功していること - 適切なビルドから成功したビルドのみを使用する オプションが有効化されている場合。
通常の、 個人ビルドではないビルドで、カスタマイズされたパラメーターはありません。
ビルドの実行以降、ビルド構成設定は変更されていません。
それ自体の依存関係ビルドもすべて適切です。
ビルドは "ハングしている" 状態ではありません。
すべての条件を満たすビルドがない場合、TeamCity は代わりに新しい上流ビルドを実行します。
ビルドの再利用を無効化する VCS 設定
一部の VCS ルート構成では、TeamCity がリビジョンを確実に計算できないため、ビルドの再利用が完全に無効化されます。 該当するのは次のとおりです:
Subversion - "チェックアウトするが変更を無視する" モード。
CVS - "タグでチェックアウト" モード。
Perforce - "Stream" または "Client" の接続設定、または "チェックアウトするラベル/リビジョン" として指定されたラベル。
StarTeam - チェックアウトモードが "ビューラベル" または "プロモーション日" に設定されている。
並列テストとビルドの再利用
常に新しいビルドを実行 の動作 (スナップショット依存関係 の 適切なものがあれば、新しいビルドを実行しないでください 設定が無効) は、メイン構成ビルドにのみ影響します。 並列テスト 機能の使用時に動的に生成される仮想ビルド構成は、以前の結果を引き続き再利用する場合があります。 新しいリポジトリコミットが検出されなかった場合、以前に失敗したテストバッチのみが新しいビルドを実行し、成功したバッチは再利用されます。
下の図では、「Composite Conf」構成は「Maven App」構成に依存しています。 後者は、2 つの並列バッチでテストを実行します。 メインの「Maven app」ビルド #18 は新たにトリガーされますが、動的に生成された「Maven app 1」構成は、以前の成功したビルド (#12) を再利用することに注意してください。

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

これを行うには、並列テスト機能がある構成に teamcity.internal.splitBuild.dependency.takeStartedBuildWithSameRevisions=false パラメーター を追加します。
この動作をサーバー上のすべての構成に適用するには、このパラメーターを 内部プロパティリストに追加します。
リビジョン同期
デフォルトでは、チェーンのすべてのメンバーが同じソーススナップショットで実行されます。 特定の依存関係で リビジョン同期を強制する を無効化すると、チェーンは独立したリビジョングループに分割されるため、そのリンクを越えてビルドを新しいリビジョンへ プロモートできます。
一般的なユースケースはデプロイです: 最新 デプロイスクリプトを使用して、古い検証済みビルドをデプロイします。
![]()
D → C → B → A というチェーンを考えます。ここでは D がコンパイルし、C が統合テストを実行し、B がシステムテストを実行し、A がデプロイします。 B の依存関係では同期が 無効 ですが、A と C では有効化されています:
D と C は同期されています - どちらもリビジョン 1 で実行されます。
B と A は同期されています - どちらもリビジョン 3 で実行されます。
C → B リンクは非同期化されているため、二つのグループで異なるリビジョンを使用できます。
これにより、B と A は引き続き最新のリビジョン 3 で実行しながら、古いコンパイル (D、リビジョン 1) を C をスキップして B に直接プロモートできます。
従うべきルールは一つです: 下流ビルドが別のパスを通じて別の上流ビルドとも同期している場合は、リンクを非同期化しないでください。 これにより、矛盾したリビジョン要件が生じます。 安全なトポロジーは二つあります:フォークの片側全体で同期を無効化する…

...または再結合する前に両方の分岐で無効にします。
