VCS トリガーの構成
VCS トリガーは、TeamCity が構成済みの VCS ルートで新しい変更を検出するたびに新しいビルドを自動的に開始し、その変更を保留中の変更に表示します。 複数の VCS トリガーをビルド構成に追加できます。
デフォルト設定の新しい VCS トリガーは、ビルド構成に保留中の変更があるとビルドをトリガーします: バージョン管理は、VCS ルートの 変更チェック間隔に従って変更をポーリングし、構成されている場合は VCS コミットフックを尊重します。 チェックアウトルールに一致した変更のみが保留中として表示されるため、トリガーによって処理されます。 短時間に複数のチェックインが行われ、TeamCity によってまとめて検出された場合、 ビルドが 1 件トリガーされます のみです。
最後の変更が検出された後、ビルドがキューに追加される前に、変更がない状態でしばらく待機する 静止期間を設定できます。
両方のオプションのグローバルデフォルト値は 60 秒で、 管理 | グローバル設定 ページでサーバーに設定できます。
スナップショット依存関係の変更時にビルドをトリガーする
ビルドチェーン (つまり、 スナップショット依存関係によって相互接続された複数のビルド) がある場合、トリガーはチェーン内の最後のビルドで構成する必要があります。 これは、以下のイメージに示す パック設定です。
VCS ビルドトリガーには、ビルドチェーンのトリガー動作を変更する別の オプションがあります。 このオプションを有効化すると、最終ビルドではなく依存関係で変更が検出された場合でも、ビルドチェーン全体がトリガーされます。
例からビルドチェーンを見てみましょう: パック設定 — 依存 — テスト — 依存 — コンパイル
VCS トリガーが パック設定 構成に設定されている場合、TeamCity が パック設定 の変更を検出すると、通常はビルドチェーン全体がトリガーされます。 コンパイル の変更は コンパイル のみをトリガーし、チェーン全体はトリガーしません。 コンパイル の VCS 変更でチェーン全体をトリガーしたい場合は、" スナップショット依存関係の変更でトリガー" オプションを有効化した VCS トリガーを、チェーンの最終ビルド構成である パック設定 に追加します。 これによってビルドの実行順序は変わりませんが、いずれかのスナップショット依存関係に変更がある場合にのみ、ビルドチェーン全体がトリガーされます。 この設定では、 コンパイル または テスト ビルド構成に VCS トリガーは必要ありません。
トリガールールが指定されている場合 (以下で説明)、それらはすべての変更 (スナップショット依存関係からの変更を含む) に適用され、ルールに一致する変更のみがビルドチェーンをトリガーします。
詳細は 依存関係を構築するページでも参照してください。
チェックインごとのトリガー
このオプションで 含まない が有効化されている場合、異なるコミッターによる複数のチェックインが行われる可能性があります。それらが検出されると、TeamCity はこれらすべての変更を含む単一のビルドだけをキューに追加します。
ビルドが高速で十分なビルドエージェントがある場合、TeamCity に新しいビルドを 各チェックインごと 開始させ、同じビルドに他の変更が含まれないようにできます。
これを行うには、 各チェックインでビルドをトリガー オプションを選択します。 同じコミッターによる場合は、複数のチェックインをビルドに含める オプションを選択し、TeamCity が保留中の変更を複数検出した場合、それらをユーザー別にグループ化し、単一のユーザーによる変更のみを含むビルドを開始します。
これは、そのような問題が発生した場合に、どの変更がビルドを壊したか、新しいテストの失敗を引き起こしたかを把握できます。
静止期間の設定
静止期間を指定することで、複数の VCS チェックインで構成される非アトミックチェックインの途中でビルドがトリガーされないようにすることができます。
静止期間 とは、最後の VCS 変更が検出されてからビルドがキューに追加されるまでの間に TeamCity が維持する期間 (秒単位) です。 この期間内にビルド構成で新しい VCS 変更が検出されると、新しい変更が検出された時間から期間が再開されます。 静止期間内に新しい VCS 変更が検出されなかった場合にのみ、ビルドがキューに追加されます。
TeamCity は静止期間中に少なくとも一度は変更が収集されたことを確認する必要があるため、実際の静止期間は、ビルド構成の VCS ルートの中で最大の 変更チェック間隔より短くならないことに注意してください。
静止期間は、デフォルト値（60 秒、 管理 | グローバル設定 ページでグローバルに変更可能）に設定することも、ビルド構成のカスタム値に設定することもできます。
ビルドキュー最適化設定
デフォルトでは、TeamCity は ビルドキューを最適化します: すでにキューに入っているビルドは、すでに開始済みのビルドまたはより新しいキュー内のビルドに置き換えられることがあります。 対応するボックスのチェックを外すことで、このデフォルトの動作を無効化できます。
VCS トリガールール
トリガールールが指定されていない場合、ビルド構成で検出された変更があればビルドがトリガーされます。 VCS ルート設定を変更し、 チェックアウトルールを指定することで、検出される変更を制御できます。
ビルドをトリガーする変更を制限するには、VCS トリガールールを使用します。 これらのルールはテキスト領域に手動で追加することも (1 行に 1 つ)、 新しいルールを追加 ボタンを使用してルールを生成することもできます (必要に応じて、下にスクロールしてボタンを表示します)。
各ルールは、「include」 (プラス で始まる) または「exclude」 (- で始まる) のいずれかです。
一般的な構文
単一ルールの一般的な構文は次のとおりです。
where:
Ant_like_wildcard: 変更されたファイルパスに一致する ワイルドカード。*および**パターンのみがサポートされており、？パターンは 含まない サポートされています。 ルール内のファイルパスは、エージェントの結果パスに一致する相対パス (/または\で始まらない) または VCS ルートを基準とした VCS パスに一致する絶対パス (/で始まる) にすることができます。 変更内の各ファイルについて、最も具体的なルール (最も長いファイルパスに一致するルール) が見つかります。 一致する "include "ルールを持つファイルまたは一致する"exclude" ルールを持たないファイルが少なくとも 1 つある場合、ビルドがトリガーされます。VCS_username: 指定した場合、対応する VCS のユーザー名を持つユーザーによって行われた変更のみにルールが制限されます。VCS_root_id: 指定した場合、対応する VCS ルートからの変更のみにルールが制限されます。VCS_comment_regexp: 指定した場合、VCS コメントに指定したテキストが含まれる変更のみにルールを制限します。 コメント内のテキストを照合するには、 Java 正規表現 パターンを使用します (以下の例を参照)。 コメントテキストに一致するテキスト部分が含まれる場合、ルールは一致します。テキスト全体に一致させるには、^および$特殊文字を含めます。
トリガールールの例
サンプル | 説明 |
|---|---|
+:. | すべてのファイルを含みます |
-:**.html | すべての |
-:user = techwriter; root = InternalSVN:/misc/doc/ *.xml | VCS ユーザー |
-:lib/ ** | ビルドソースの |
-:comment = minor:** | 変更チェックのコメントに |
-:comment = ^ oops $:** | コメントが |
+:comment =#teamcity:** | コメントに |
+:comment =（？ s）#teamcity.*#major:** | コメントに 例: 次のコメントがビルドをトリガーします:
#teamcity the first line
#major the second line
|
ブランチフィルター
ブランチフィルターで続きを読む。
トリガールールとブランチフィルターの組み合わせ
トリガールールとブランチフィルターは および によって結合され、 両方の条件が満たされた場合のみ ビルドがトリガーされることを意味します。
例: トリガー規則フィールドにコメントテキストを指定してブランチ指定を指定した場合、コミットが特殊テキストを持ち、ブランチフィルターと突き合わせられたブランチにある場合にのみビルドがトリガーされます。
ブランチマージ時のビルドのトリガー
VCS トリガーはブランチを完全に認識しており、チェックインがブランチで検出されるとビルドをトリガーします。
あるブランチから別のブランチへ変更がマージ / 早送りされるとき、厳密に言えばコードに実際の変更はありません。 デフォルトでは、VCS トリガーは次のように動作します。
二つの非デフォルトブランチのマージ/ファストフォワード時: ビルド内の変更は同じブランチ内の以前のビルドを考慮して計算されるため、別のブランチに同じコミットのビルドがある場合、トリガーは同じコミットを指す別のブランチでビルドを開始します。
デフォルトブランチがマージ/ファストフォワード対象のブランチのいずれかである場合、変更は常にデフォルトブランチを基準に計算されます。デフォルトブランチに同じリビジョンのビルドがある場合、TeamCity は同じリビジョンで新しいビルドを実行しません。
トリガーされたビルドのカスタマイズ
トリガーの設定の ビルドカスタマイズ タブでは、このトリガーによって開始されたビルドのカスタムパラメーターを構成できます。 カスタムビルドを実行するダイアログと同様に、 ビルドパラメーターの値を上書きし、ビルド前に チェックアウトディレクトリをクリーンアップするかどうかを選択できます。
このタブでは、現在の ビルド構成 で使用されている任意の パラメーター の値をカスタマイズできます。 また、新しいパラメーターを追加することもでき、そのパラメーターはこのトリガーによって開始されるビルドでのみ使用できます。 現在のビルドに他のビルドに対する スナップショット依存関係 がある場合、このようなパラメーターを使用して、依存ビルド構成の 特定のプロパティをオーバーライド することもできます: このためには reverse.dep.<dependencyBuildID>.<property> 構文を使用します。
トリガー内でビルドパラメーターを再定義してから パラメーター で元のパラメーターを削除すると、その再定義された値がトリガー自体のプレーンテキストパラメーターに変換されることに注意してください。 安全な値をカスタマイズするときは、 「パスワード」の種類と一緒に保存された場合にのみ隠され、プレーンテキストに変換された場合に読み取り可能になるため、これを考慮することが重要です。
TeamCity では類似したタスクを複数の方法で解決でき、場合によっては別々のビルド構成を作成するほうが依然として望ましいことがあります。 たとえば、同じ構成でカスタム実行が多すぎる場合、TeamCity が各ビルドの正確な所要時間を予測しにくくなることがあります。 多数の異なるパラメーターでビルドをトリガーする必要がある場合は、 ビルド構成テンプレート を作成し、それぞれ独自のパラメーターを持つ複数の構成のブループリントとして使用することをお勧めします。