ブランチフィルター
VCS ルートに ブランチが指定されている場合、TeamCity のさまざまな操作で ブランチフィルターオプションが使用できるようになります。
ブランチフィルターの使用箇所
現在、ブランチフィルターは次の TeamCity 設定ページで構成できます:
設定 | ブランチフィルターの説明 |
|---|---|
ビルド構成の バージョン管理設定 | ビルド構成に使用できるブランチのセットを制限します。 このブランチフィルターは、他のブランチフィルターの前に適用され、カスタムビルドダイアログに表示されるブランチ、およびトリガーとビルドフィーチャーに表示されるブランチを制限します。 |
現在の構成のビルドでアーティファクトが使用される依存関係ビルドを、一致するブランチのビルドに制限します。 | |
このビルド終了トリガーによってビルドが監視されるブランチのセットを制限します。 | |
この VCS トリガーによってビルドをトリガーできるブランチのセットを制限します。 | |
トリガーを適用するブランチのセットを制限します。
| |
ブランチフィルターを設定して、指定された基準に一致するブランチでのみ失敗したビルドを再実行します。 | |
VCS ラベル付けビルド機能 | ブランチのセットを、ラベルが適用されるビルドに制限します。 |
自動マージビルド機能 | ビルドのソースがマージされるブランチのセットを制限します。 |
指定されたブランチからのビルドでのみアラートを受信するようにフィルターを設定します。 デフォルトでは、デフォルトのブランチのみが監視されます。 | |
プルリクエストビルド機能 | プル要求を監視およびトリガーするブランチを指定します。 この機能のフィルターは、短縮された論理名 ( |
クリーンアップ規則が適用されるブランチの命名パターンを指定します。 「ルールを適用 」設定に応じて、一致する各ブランチごとに選択した数のビルド、または一致するブランチのセットごとに 1 回選択した数のビルドに適用できることに注意してください。 |
単一のルートの上に複数のブランチフィルターが構成されている場合、次の優先順位が適用されます。
VCS ルート設定の ブランチ仕様は、監視対象のブランチの初期セットを定義します。
指定した場合、ビルド構成の バージョン管理設定 のブランチフィルターは、ブランチの初期セットを絞り込むことができます。
指定した場合、ビルドトリガーの設定でブランチフィルターが、フィルターによって宣言されたサブセットに適用されます(2)。
ブランチフィルターのフォーマット
ブランチをフィルターするには、 +|-:論理_ブランチ_お名前 ルールの改行区切りリストを使用します。ここで、 論理_ブランチ_お名前 は TeamCity UI に表示されるお名前です (例: マスター)。 お名前では大文字と小文字が区別されます。
+: ルールは、一致するブランチを受け入れられたブランチのリストに含め、 -: ルールはブランチをリストから除外します。
各ルールには、任意のワイルドカード * プレースホルダーをひとつ含めることができ、これはひとつ以上の文字に一致します: +|-:お名前* はブランチ お名前 1 に一致しますが、 しません はブランチ お名前 に一致しないため、明示的に追加する必要があります。
ブランチフィルターでパラメーター参照を使用できます。
単一のブランチがブランチフィルターの複数の行と一致する場合、最も具体的な(パターンと一致する最も少ない文字)最後の規則が適用されます。 つまり、フィルターにブランチに一致する正確なパターン(つまり、 * ワイルドカードのないパターン)が含まれている場合、最後のそのようなパターンが使用されます。
他の例:
デフォルトのブランチのみが受け入れられます。
+:<default>デフォルト以外のすべてのブランチが受け入れられます。
+:* -:<default>機能-接頭辞を持つブランチのみが受け入れられます+:feature-*空のブランチフィルター(すべてのブランチが受け入れられます):
+:*
プルリクエストブランチフィルター
+|-プルリクエスト: <パラメーター 1>=<値 1> <パラメーター 2>=<値 2> …附近},{ 構文を使用して、特定のプル (マージ) リクエストブランチを対象とするフィルターを作成します。 この汎用構文を使用すると、論理的なブランチ名だけでなく、より具体的なパラメーターを考慮した、きめ細かい VCS に依存しないフィルター式を定義できます。
<パラメーター>=<値> 式は論理 および 演算子を使用して結合されます。つまり、プル (マージ) リクエストのブランチがフィルターを通過するには、すべての条件を満たす必要があります。 現在、次のパラメーターと値がサポートされています:
ターゲットおよびソース— 受信および送信ブランチでリクエストをフィルターできます。 リクエストがフォークされたリポジトリから発信された場合、ソースパラメーターは常に偽になります。 サポートされる値: オプションの ワイルドカードを含む論理ブランチ名。ソースリポジトリ— 同じリポジトリ (たとえば、1 つのリポジトリブランチを別のリポジトリにマージする場合)、フォークされたリポジトリ、その両方からのプルリクエストのみを対象にすることができます。 サポートされる値:同じ、フォーク、任意ドラフト— ドラフトプルリクエストを受け入れるかどうかを指定します。 このパラメーターは、GitHub と GitLab に対してのみ有効です。 サポートされている値: ドラフトとしてラベル付けされたリクエスト のみ を受け入れる場合は真、非ドラフトリクエスト のみ を受け入れる場合は偽
github_role— 送信者ロール(リポジトリ組織を基準)別にプル(マージ)リクエストをフィルタリングできます。 サポートされる値:コラボレーター、コントリビューター、メンバー、所有者、なし(大文字と小文字は区別されません)。
ブランチフィルターを設定するときは、マジックワンドボタンをクリックし、 プルリクエスト条件 タブに切り替えて、ビジュアルエディターを使用してフィルター式を追加します。

ワイルドカードとパターン
任意の文字列のワイルドカードとしてアスタリスク ("*" ) を使用します。 例: +プルリクエスト:* および -プルリクエスト:* ルールでは、トリガーがすべての受信要求を受け入れるか無視するかを選択できます。
次のルールにより、オブジェクトはターゲットブランチが「dev/」で始まる要求のみを受け入れることができます。
フィルターの優先順位
プルリクエストフィルター式は、通常の +|-:<ブランチ名> 式と同じ方法で、最初のものから順番に適用されます。 つまり、競合する式がある場合は、最後の式の優先順位が最も高くなります。 たとえば、次のルールセットでは、親オブジェクトが利用可能なすべてのブランチを受け入れた後、すべてのプルリクエストブランチを除外し、最後に組織メンバーが作成したプルリクエストを再度有効にできます。
次のフィルターの組み合わせは、 メイン ブランチをターゲットとしている場合でも、フォークされたリポジトリからのプルリクエストを拒否します (ソースリポジトリ 条件が最後に来るため)。
サンプル
次の Kotlin DSL サンプルは、 VCS トリガーと スケジュールトリガーを組み合わせて次の設定を実装する方法を示しています:
既存のブランチの変更は、TeamCity が検出するとすぐにビルドされます;
組織メンバーが作成したドラフトではないプル (マージ) リクエストは、TeamCity がそれらに関する情報を収集するとすぐにビルドされます;
共同作業者およびコントリビューターからの非ドラフトプル (マージ) リクエストは、これらのリクエストが 2 つの安定したリポジトリブランチのいずれかを対象としている場合、3:00 AM で夜間にビルドされます。