VCSトリガーの設定

TeamCityが設定されたVCSルートで新しい変更を検出するたびに、VCSは自動的に新しいビルドを開始し、保留中の変更にその変更を表示します。ビルド構成に追加できるVCSトリガーは1つだけです。

デフォルト設定の新しいVCSトリガーは、ビルド設定に保留中の変更があるとビルドをトリガーします。バージョン管理は、設定されている場合はVCSコミットフックを遵守するVCSルートの変更間隔の確認に従って変更をポーリングします。チェックアウト規則に一致した変更のみが保留中として表示され、トリガーによって処理されます。短時間のうちに複数のチェックインが行われ、TeamCityによって一緒に検出された場合、1回のビルドのみがトリガーされます。

最後の変更が検出された後、ビルドがキューに入れられる前に、何も変更せずにしばらく待つように静止期間を構成できます。

両方のオプションのグローバルデフォルト値は60秒で、管理 | グローバル設定ページでサーバーに設定できます。

下記のオプションを使用して、必要に応じてVCSトリガーを調整できます。

スナップショット依存関係の変更に基づいてビルドをトリガーする
チェックインごとのトリガー
- 静かな期間の設定
- ビルドキューの最適化設定
VCSトリガールール

スナップショット依存関係の変更に基づいてビルドをトリガーする

ビルドチェーン（スナップショット依存関係によって相互接続された多数のビルド）がある場合、トリガーはチェーンの最後のビルドで構成されます。これは下のイメージのパック設定です。

VCSビルドトリガーには、ビルドチェーンのトリガー動作を変更する別のオプションがあります。このオプションを有効にすると、最終ビルドではなく依存関係で変更が検出された場合でも、ビルドチェーン全体がトリガーされます。

例からビルドチェーンを取りましょう: pack setup - 依存 - tests - 依存 - compile

pack setup 構成でVCSトリガーが設定されていると、通常TeamCityが pack setupの変更を検出したときにチェーン全体がトリガーされます。 compile を変更しても compile のみがトリガされ、チェーン全体はトリガされません。 compileでVCSを変更したときにチェーン全体をトリガーするには、チェーンの最終ビルド構成 pack setupに "スナップショット依存関係の変更をトリガー" オプションを有効にしてVCSトリガーを追加します。これはビルドが実行される順番を変更することはありませんが、スナップショットの依存関係のいずれかに変更がある場合にのみ、ビルドチェーン全体をトリガーするだけです。このセットアップでは、compile または tests ビルド構成にVCSトリガーは必要ありません。

トリガルールが（説明指定されている場合以下）、それらは、（スナップショットの依存からの変更を含む）すべての変更に適用され、ルールに合致する唯一の変更は、ビルドチェーンをトリガします。

詳細は依存関係を構築するページでも参照してください。

チェックインごとのトリガー

このオプションが有効になっていない場合は、異なるコミッターによるいくつかのチェックインが可能です。そしてそれらが検出されると、TeamCityはこれらすべての変更と共にキューに1つのビルドのみを追加します。

高速ビルドと十分な数のビルドエージェントがある場合は、TeamCityに新しいビルドチェックインごとにを起動させて、同じビルドに他の変更が加えられないようにすることができます。
それには、チェックインのたびにビルドを開始するオプションを選択してください。同じコミッターからのものであれば、ビルドに複数のチェックインを含めるオプションを選択し、TeamCityが保留中の変更の数を検出すると、それらはユーザーごとにグループ化され、シングルユーザーの変更のみを含むビルドが開始されます。

これは、そのような課題が発生した場合に、どの変更がビルドを壊したか、または新しいテストの失敗を引き起こしたかを把握できます。

静かな期間の設定

クワイエット期間を指定することで、複数のVCSチェックインからなる非アトミックチェックインの途中でビルドがトリガーされないようにすることができます。

クワイエット期間とは、最後のVCSの変更が検出されてからビルドがキューに追加されるまでの間にTeamCityが維持する期間（秒単位）です。期間内にビルド構成で新しいVCS変更が検出された場合、その期間は新しい変更検出時刻からやり直します。ビルドは、クワイエット期間内に新しいVCSの変更が検出されなかった場合にのみキューに追加されます。

TeamCityは、変更が少なくとも1回は停止期間中に収集されたことを確認する必要があるため、実際の停止期間は、ビルド構成のVCSルート間の最大変更間隔チェック間隔より短くなることはありません。

静止期間は、デフォルト値（60秒、管理 | グローバル設定ページでグローバルに変更可能）に設定することも、ビルド構成のカスタム値に設定することもできます。

ビルドキューの最適化設定

デフォルトでは、TeamCity はビルドキューを最適化します。すでにキューに入れられているビルドは、既に開始されているビルドまたは最近のキューに入れられているビルドと置き換えることができます。対応するボックスのチェックを外すと、このデフォルトの動作を無効にできます。

VCSトリガールール

トリガールールが指定されていない場合は、ビルド構成に対して変更が検出されたときにビルドがトリガーされます。VCSのルート設定を変更してチェックアウト規則を指定することで、どのような変更を検出するかを制御できます。

ビルドをトリガーする変更を制限するには、VCSトリガールールを使います。これらの規則をテキスト領域に手動で（1行に1つずつ）追加するか、または新しいルールを追加オプションを使用して生成することができます。

各規則は、"include" （ "+"で始まる）または "exclude" （ "-"で始まる）です。

一般的な構文

単一ルールの一般的な構文は次のとおりです。

+|-[:[user=VCS_username;][root=VCS_root_id;][comment=VCS_comment_regexp]]:Ant_like_wildcard

where:

Ant_like_wildcard : 変更されたファイルパスと一致するワイルドカード。 * と ** パターンのみがサポートされ、? パターンはサポートされません。ルール内のファイルパスは、エージェント上の結果のパスと一致するように相対的（ / または \で開始されていない）でも、VCSルートに対して相対的なVCSパスと一致するように絶対的（ /で開始される）でもかまいません。変更の中のファイルごとに、最も具体的な規則（最も長いファイルパスに一致する規則）が見つかります。一致する "include"ルールを持つファイルが少なくとも1つあるか、または "exclude"ルールに一致するファイルがない場合、ビルドがトリガーされます。
VCS_ユーザー名 : 指定した場合、対応するVCSのユーザー名を持つユーザーによって行われた変更のみにルールが制限されます。
VCS_root_id : 指定した場合、対応するVCSルートからの変更のみにルールが制限されます。
VCS_comment_regexp : 指定した場合、VCSコメントに指定したテキストが含まれる変更のみにルールが制限されます。コメント内のテキストを一致させるには、Java正規表現パターンを使用します（以下の例を参照）。コメントテキストに一致したテキスト部分が含まれている場合、ルールは一致します。テキスト全体を一致させるには、^ と $ の特殊文字を含めます。

トリガルールの例

サンプル	説明
`+:.`	すべてのファイルを含みます
`-:**.html`	すべての `.html` ファイルがビルドをトリガーするのを除外します。
`-:user=techwriter;root=InternalSVN:/misc/doc/*.xml`	VCSユーザー "techwriter" によって内部SVNという名前のVCSルートの `misc/doc` ディレクトリーにチェックインされた `.xml` ファイルによってトリガーされるビルドを除外します（VCS設定で定義されているとおり）。パスは絶対パス（「/」で始まる）であるため、ファイルパスはVCSルートから一致します。
`-:lib/**`	（エージェントに表示されるように）ビルドソースの `lib` ディレクトリーの更新によってビルドがトリガされるのを防ぎます。パスは相対パスなので、（VCSのルートチェックアウト規則を処理して）ディレクトリーに配置されたすべてのファイルによってビルドがトリガーされることはありません。
`-:comment=minor:**`	変更チェックのコメントに "minor" という単語が含まれている場合、ビルドがトリガーされないようにします。
`-:comment=^oops$:**`	コメントが "oops" という単語のみで構成されている場合はトリガされません（Java正規表現の原則によると、`^` と `$` は文字列の先頭と末尾を表します）。

ブランチフィルター

さらに読むブランチフィルター

トリガルールとブランチフィルタの組み合わせ

トリガー・ルールとブランチフィルターはANDによって結合されます。つまり、両方の条件が満たされた場合にのみビルドがトリガーされます。

例：トリガー規則フィールドにコメント・テキストを指定してブランチ指定を指定した場合、コミットが特殊テキストを持ち、ブランチフィルターと突き合わせられたブランチにある場合にのみビルドがトリガーされます。

ブランチマージでビルドを開始する

VCSトリガーはブランチを完全に認識しており、チェックインがブランチで検出されるとビルドをトリガーします。

あるブランチから別のブランチへ変更がマージ/早送りされるとき、厳密に言えばコードに実際の変更はありません。デフォルトでは、VCSトリガーは次のように動作します。

2つのデフォルトではないブランチのマージ/早送り：同じブランチ内の以前のビルドに関してビルド内の変更が計算されるため、別のブランチ内の同じコミットにビルドがある場合、トリガーはその中でビルドを開始します。別のブランチが同じコミットを指しています。
デフォルトのブランチがマージ/早送りのブランチの1つである場合、変更は常にデフォルトのブランチに対して計算されます。デフォルトのブランチに同じリビジョンのビルドがある場合、TeamCityは同じビルドに対して新しいビルドを実行しません。リビジョン。