チェーンの依存関係の設定

スナップショットの依存関係

スナップショットの依存関係は、チェーン内の 2 つのビルド構成をリンクします。「スナップショット」という用語は、ソースリビジョンの同期を指します。アップストリームビルドとダウンストリームビルドの両方が同じコードスナップショットを共有するため、チェーンが意味を持つための重要な保証となります。

ビルド構成にスナップショットの依存関係を追加するには:

1. 構成設定を開き、依存関係設定タブに移動します。

2. 新しいスナップショット依存関係を追加するをクリックし、上流構成を選択します。

パイプラインの依存関係

パイプラインの依存関係はパイプラインを他のパイプラインまたは従来のビルド構成にリンクします。

パイプラインの依存関係を追加するには:

1. パイプラインレベルの設定を開くには、パイプラインキャンバス領域内の任意の場所（ジョブの外側）をクリックします。

2. パイプラインの依存関係セクションの追加をクリックしてください。

3. 依存先リストからアップストリームパイプラインまたはビルド構成を選択してください。

依存関係の設定

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

依存先

このオブジェクトを開始する前に完了する必要のある上流の構成またはパイプラインを選択してください。

リビジョン同期を強制する

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 は新しいビルドを開始する代わりに、適切なビルドを探して使用します。

並列テストとビルドの再利用

常に新しいビルドを実行する動作（スナップショット依存関係 適切なものがあれば、新しいビルドを実行しないでください設定が無効になっている状態）は、メイン構成のビルドのみに影響します。並列テスト機能使用時に動的に生成される仮想ビルド構成は、以前の結果を再利用する場合があります。新しいリポジトリコミットが検出されなかった場合、以前に失敗したテストバッチのみが新しいビルドを実行し、成功したバッチは再利用されます。

下の図では、「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 間のリンクは非同期であるため、2 つのグループは異なるリビジョンを使用できます。

これにより、古いコンパイル（D、リビジョン 1）を C をスキップして直接 B に昇格させることができ、B と A は引き続き最新のリビジョン 3 で動作します。

守るべき唯一のルールは、ダウンストリームビルドが別のパスを介してアップストリームビルドと同期している場合、リンクの同期を解除しないことです。これは矛盾するリビジョン要件を生み出します。安全なトポロジーは 2 つあります。フォークの片側全体で同期を無効にする ...

…あるいは、再合流する前に両足が麻痺した状態になる。