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

ワイルドカードとパターン
任意の文字列のワイルドカードとしてアスタリスク ("*" ) を使用します。例: +pr:* および -pr:* ルールでは、トリガーがすべての受信要求を受け入れるか無視するかを選択できます。
次のルールにより、オブジェクトはターゲットブランチが「dev/」で始まる要求のみを受け入れることができます。
フィルターの優先順位
プルリクエストフィルター式は、通常の +|-:<branch_name> 式と同じ方法で適用されます。つまり、最初の式から 1 つずつ適用されます。つまり、式が競合する場合は、最後の式が最も優先されます。例: 次のルールセットでは、親オブジェクトが利用可能なすべてのブランチを受け入れるようにし、次にすべてのプルリクエストブランチを除外し、最後に組織のメンバーが作成したプルリクエストを再度有効にします。
次のフィルターの組み合わせは、main ブランチをターゲットとしている場合でも、フォークされたリポジトリからのプルリクエストを拒否します (sourceRepo 条件が最後に来るため)。
サンプル
次の Kotlin DSL サンプルは、VCS トリガーとスケジュールトリガーを組み合わせて次の設定を実装する方法を示しています。
既存のブランチの変更は、TeamCity が検出するとすぐにビルドされます。
組織のメンバーによって作成された非ドラフトのプル (マージ) リクエストは、TeamCity がそれらに関する情報を収集するとすぐに作成されます。
共同作業者およびコントリビューターからの非ドラフトプル (マージ) リクエストは、これらのリクエストが 2 つの安定したリポジトリブランチのいずれかを対象としている場合、3:00 AM で夜間にビルドされます。
関連ページ:
VCS ルートの設定
VCS ルートは、TeamCity ←→ VCS リポジトリ通信の基礎です。この不可欠な要素は、リポジトリのチェックアウト、コードソースのタグ付け、ビルドステータスの VCS への返信など、さまざまな操作を実行するために必要な VCS プロバイダーへの接続を定義します。VCS ルートには次の情報が保存されます。TeamCity がリモートファイルをプルおよびプッシュするために使用する URL を取得してプッシュします。ブランチ情報: TeamCity が追跡する必要があるリポジトリブランチのリスト...
機能ブランチを使用した作業
分散バージョン管理システム (DVCS) の機能ブランチを使用すると、メインの開発とは独立して機能に取り組み、機能のすべての変更をブランチにコミットし、機能が完了したら変更をメインのブランチにマージできます。このアプローチは、ソフトウェア開発チームに多くの利点をもたらしますが、専用のサポートがない継続的インテグレーションサーバーでは、ビルド構成の重複が頻繁に発生したり、可視性が低下したり、最終的にはプロセスに対する制御が失われるなど、多くの問題も発生します。機能ブランチの TeamCity サポ...
VCS 設定値の設定
バージョン管理システム(VCS)は、プロジェクトのソースファイルのリビジョンを追跡するためのシステムです。SCM(ソースコード管理)またはリビジョン管理システムとも呼ばれます。次の VCS は、そのまま TeamCity でサポートされています:Git、Subversion、Mercurial、Perforce、Azure DevOps、CVS、StarTeam。バージョン管理システムへの接続は、TeamCityVCS ルートによって定義されます。TeamCity のプロジェクトまたは...
アーティファクトの依存関係
このページでは、あるビルドから別のビルドにファイルを渡すことができる TeamCity アーティファクトの依存関係の構成について詳しく説明します。例: 一般的なデプロイビルド構成は、他の (本番) 構成によって生成されたファイルを公開します。アーティファクトは以下から渡すことができます: 同じビルドチェーン内のターゲット構成の前に実行される構成。ターゲット構成と同じビルドチェーンの一部ではない個別の構成。同じ構成の以前のビルド。Web UI を使用したアーティファクトの依存関係の設定:ビルド構成...
ビルド完了トリガの設定
ビルド終了トリガーは、選択したビルド構成のビルドが終了したときに、現在のビルド構成のビルドを開始します。重要なポイント:ビルドトリガーを終了が構成 A に追加されると、ターゲット構成 B を監視し、B が別のビルドを完了するたびに新しい A ビルドを生成します。ターゲット構成のビルドが成功した場合にのみビルドをトリガーするかどうかを選択できます。完了ビルドトリガーは、同じターゲット構成を指すスナップショット依存関係の恩恵を受けます。ターゲット構成のすべての新しいビルドを追跡する代わりに、ターゲ...
VCS トリガーの設定
VCS トリガーは、TeamCity が構成済みの VCS ルートの新しい変更を検出するたびに新しいビルドを自動的に開始し、保留中の変更の変更を表示します。複数の VCS トリガーをビルド構成に追加できます。デフォルト設定の新しい VCS トリガーは、ビルド構成に保留中の変更があるとビルドをトリガーします。バージョン管理は、VCS コミットフック(設定されている場合)を尊重する VCS ルートの変更チェック間隔に従ってポーリングされます。チェックアウトルールに一致する変更のみが保留中として表示され...