セットアップ キットのビルドには次の構成があると想定しています。
- CI ビルドに設定された「Finish Build Trigger」。CI ビルドが正常に完了するたびに、セットアップ キット ビルドが実行されます。
- セットアップ キットが実行されるたびに、VCS から独自のソースを取得するための VCS ルート。
問題は、CI ビルドに 2 分かかり、そのビルド中にさらに CI の変更がある場合、セットアップ キット ビルドは、トリガーする CI ビルドのソースではなく、開始時のソースを使用することです。ビルドをトリガーするのは VCS の変更ではなく、CI プロジェクトであるため、VCS の変更の有無とは関係ありません。
スナップショットの依存関係
欠けているのはスナップショットの依存関係です。これは、「依存関係」の構成手順 (#6) で利用できます。これでもプロジェクト トリガーは実行されますが、CI ビルドとセットアップ キット ビルドが同じタイムスタンプのまったく同じソース コードを使用するようになります。引き続き 2 つのセットアップ キット ビルドを取得しますが、それぞれが CI ビルドに直接関連付けられます。
休止期間
CI ビルドが成功するたびにセットアップ キット ビルドがトリガーされるため、CI ビルドの数を減らすという別のオプションがあります。CI ビルドで休止期間を有効にすることで、CI は変更があり、X 時間内に新しいコミットがない場合にのみ開始されます。「何かが変わった。30 秒待って、さらに変更があるかどうかを確認しましょう。新しいものがない場合は、ビルドをトリガーします。」これにより、2 つのコミットが 1 つの CI ビルドに配置され、結果として 1 つのセットアップ キット ビルドが作成されます。
同様に、セットアップ キットの Finish Build トリガーを削除して、休止期間のある VCS トリガーに変更できます。静止期間を CI プロジェクトの実行にかかる時間よりも少し長く設定します。これにより、コミットごとに CI ビルドを作成できますが、クイック コミットが多数ある場合はセットアップ キット ビルドがグループ化されます。欠点は、成功した CI ビルドと関連付けられなくなることです。そのため、CI ビルドが失敗した状態であっても、2 分間 (休止期間に関係なく) 新しい変更がない場合は、セットアップ キットが起動します。