パイプラインを 1 つずつトリガーする
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
大規模な製品には、相互に依存する複数のコンポーネントがあります。 多くの場合、これらのコンポーネントは個別に構築されます。 アップストリーム コンポーネント (ライブラリなど) が変更された場合、ダウンストリームの依存関係を再構築して再検証する必要があります。
このような状況では、トリガー パイプラインが正常に完了したときにパイプラインを実行するパイプライン トリガーを追加します。
手記
以前は、YAML パイプラインのクラシック エディターに移動し、UI で ビルド完了トリガー を構成しました。 そのモデルは引き続き機能しますが、推奨されなくなりました。 推奨される方法は、YAML ファイル内で直接パイプライン トリガーを指定することです。 クラシック エディターで定義されているビルド完了トリガーには、パイプライン トリガーで対処されているさまざまな欠点があります。 たとえば、ビルド完了トリガーを使用する場合、トリガーされるパイプラインと同じブランチでパイプラインを起動する方法はありません。
パイプライン設定 UI を使用して定義されたトリガーは、YAML トリガーよりも優先されます。 UI のスケジュールされたトリガーの YAML パイプラインからの削除については、「UI の設定で YAML のスケジュールされたトリガーをオーバーライドする」をご覧ください。
パイプライン リソース トリガーを構成する
別のパイプラインの完了時にパイプラインをトリガーするには、パイプライン リソース トリガーを構成します。
次の例では、security-lib-ci
パイプラインの実行が完了した後に app-ci
という名前のパイプラインが実行されるように、パイプライン リソース トリガーを構成します。
この例には、次の 2 つのパイプラインがあります。
security-lib-ci
- このパイプラインが最初に実行されます。# security-lib-ci YAML pipeline steps: - bash: echo "The security-lib-ci pipeline runs first"
app-ci
- このパイプラインには、security-lib-ci
パイプラインの実行が完了するたびに自動的に実行されるようにapp-ci
パイプラインを構成するパイプライン リソース トリガーがあります。# app-ci YAML pipeline # We are setting up a pipeline resource that references the security-lib-ci # pipeline and setting up a pipeline completion trigger so that our app-ci # pipeline runs when a run of the security-lib-ci pipeline completes resources: pipelines: - pipeline: securitylib # Name of the pipeline resource. source: security-lib-ci # The name of the pipeline referenced by this pipeline resource. project: FabrikamProject # Required only if the source pipeline is in another project trigger: true # Run app-ci pipeline when any run of security-lib-ci completes steps: - bash: echo "app-ci runs after security-lib-ci completes"
- pipeline: securitylib
パイプライン リソースの名前を指定します。 パイプライン リソース変数の使用や成果物のダウンロードなど、パイプラインの他の部分からパイプライン リソースを参照する場合は、ここで定義されているラベルを使用します。source: security-lib-ci
は、このパイプライン リソースによって参照されるパイプラインの名前を指定します。 パイプラインの名前は、Azure DevOps ポータルから、Pipelines ランディング ページなど、いくつかの場所で取得できます。 既定では、パイプラインには、パイプラインを含むリポジトリの名前が付けられます。 パイプラインの名前を更新するには、「パイプラインの設定 を参照してください。 パイプラインがフォルダーに含まれている場合は、先頭の\
を含むフォルダー名を含めます (例:\security pipelines\security-lib-ci
)。project: FabrikamProject
- トリガーパイプラインが別の Azure DevOps プロジェクトにある場合は、プロジェクト名を指定する必要があります。 ソース パイプラインとトリガーされたパイプラインの両方が同じプロジェクト内にある場合、このプロパティは省略可能です。 この値を指定してもパイプラインがトリガーされない場合は、このセクションの最後にあるメモを参照してください。trigger: true
- ソース パイプラインの任意のバージョンが完了したときにパイプラインをトリガーするには、この構文を使用します。 実行をトリガーするソース パイプラインの完了バージョンをフィルター処理する方法については、この記事の次のセクションを参照してください。 フィルターが指定されている場合、ソース パイプラインの実行は、すべてのフィルターと一致して実行をトリガーする必要があります。
トリガー元のパイプラインとトリガーされたパイプラインが同じリポジトリを使用している場合、両方のパイプラインは、他方をトリガーするときに同じコミットを使用して実行されます。 これは、最初のパイプラインがコードをビルドし、2 番目のパイプラインでテストする場合に役立ちます。 ただし、2 つのパイプラインが異なるリポジトリを使用する場合、トリガーされるパイプラインでは、パイプライン完了トリガーのに関する
手記
一部のシナリオでは、手動ビルドとスケジュールされたビルドの既定のブランチに refs/heads
プレフィックスが含まれていません。 たとえば、既定の分岐は、refs/heads/main
ではなく main
に設定できます。 このシナリオでは、別のプロジェクトからのトリガーは機能しません。 project
をターゲット パイプライン以外の値に設定するときに問題が発生した場合は、その値を別のブランチに変更し、使用する既定のブランチに戻すことで、既定のブランチを更新して refs/heads
を含めることができます。
パイプライン完了トリガーの構成は、YAML テンプレートではサポートされていません。 引き続きテンプレートでパイプライン リソースを定義できます。
分岐フィルター
必要に応じて、トリガーの構成時に含めるブランチまたは除外するブランチを指定できます。 分岐フィルターを指定すると、分岐フィルターに一致するソース パイプラインの実行が正常に完了するたびに、新しいパイプラインがトリガーされます。 次の例では、app-ci
パイプラインは、releases/old*
を除く任意の releases/*
ブランチで security-lib-ci
が完了した場合に実行されます。
# app-ci YAML pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
exclude:
- releases/old*
親がトリガーされる異なるブランチに対して子パイプラインをトリガーするには、親がトリガーされるすべての分岐フィルターを含めます。 次の例では、releases/old*
を除き、releases/*
ブランチまたはメイン ブランチで security-lib-ci
が完了すると、app-ci
パイプラインが実行されます。
# app-ci YAML pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
- main
exclude:
- releases/old*
手記
分岐フィルターが機能しない場合は、プレフィックス refs/heads/
を使用してみてください。 たとえば、releases/old*
の代わりに refs/heads/releases/old*
を使用します。
タグ フィルター
手記
パイプライン リソースのタグ フィルター サポートには、Azure DevOps Server 2020 Update 1 以上が必要です。
trigger
フィルターの tags
プロパティは、どのパイプライン完了イベントがパイプラインをトリガーするかを指定します。 トリガーパイプラインが tags
リスト内のすべてのタグと一致する場合、パイプラインが実行されます。
resources:
pipelines:
- pipeline: MyCIAlias
source: Farbrikam-CI
trigger:
tags: # This filter is used for triggering the pipeline run
- Production # Tags are AND'ed
- Signed
手記
パイプライン リソースには、tags
プロパティもあります。 パイプライン リソースの tags
プロパティは、パイプラインが手動でトリガーされたとき、またはスケジュールされたトリガーによって成果物を取得するために実行されるパイプラインを決定するために使用されます。 詳細については、「リソース:パイプライン」と「成果物バージョンの評価 」を参照してください。
ステージフィルター
手記
パイプライン リソース トリガーのステージ フィルターには、Azure DevOps Server 2020 Update 1 以上が必要です。
stages
フィルターを使用して、トリガーパイプラインの 1 つ以上のステージが完了したときにパイプラインをトリガーできます。 複数のステージを指定した場合、一覧に示されているすべてのステージが完了すると、トリガーされるパイプラインが実行されます。
resources:
pipelines:
- pipeline: MyCIAlias
source: Farbrikam-CI
trigger:
stages: # This stage filter is used when evaluating conditions for
- PreProduction # triggering your pipeline. On successful completion of all the stages
- Production # provided, your pipeline will be triggered.
ブランチに関する考慮事項
手動ビルドおよびスケジュールされたビルド設定()では、パイプライン完了トリガーは、
パイプラインが完了すると、Azure DevOps ランタイムは、完了したパイプラインを参照するパイプライン完了トリガーを持つパイプラインのパイプライン リソース トリガー ブランチ フィルターを評価します。 パイプラインには異なるブランチに複数のバージョンを含めることができるため、ランタイムは、Default branch for manual and scheduled builds
設定で指定されたブランチのパイプライン バージョンの分岐フィルターを評価します。 一致するものがある場合、パイプラインは実行されますが、トリガーされたパイプラインが完了したパイプラインと同じリポジトリにあるかどうかに応じて、実行されるパイプラインのバージョンが異なるブランチにある可能性があります。
- 2 つのパイプラインが異なるリポジトリにある場合は、
Default branch for manual and scheduled builds
によって指定されたブランチ内のトリガーされたパイプライン バージョンが実行されます。 - 2 つのパイプラインが同じリポジトリ内にある場合、トリガーパイプラインと同じブランチでトリガーされたパイプラインバージョンが実行されます (トリガー条件が満たされた時点でそのブランチのパイプラインのバージョンを使用します)。そのブランチが
Default branch for manual and scheduled builds
とは異なる場合でも、そのバージョンに完了したパイプラインのブランチと一致するブランチ フィルターがない場合でも実行されます。 これは、完了したパイプライン ブランチにあるバージョンのブランチ フィルターではなく、Default branch for manual and scheduled builds
ブランチからのブランチ フィルターを使用してパイプラインを実行するかどうかを判断するためです。
パイプライン完了トリガーが起動していないと思われる場合は、トリガーされたパイプラインの [手動のビルドとスケジュールされたビルドの既定のブランチ] 設定の値を確認します。 そのブランチのバージョンのパイプラインのブランチ フィルターは、パイプライン完了トリガーがパイプラインの実行を開始するかどうかを判断するために使用されます。 既定では、Default branch for manual and scheduled builds
はリポジトリの既定のブランチに設定されますが、パイプラインの作成後に変更できます。
パイプライン完了トリガーが起動しない一般的なシナリオは、新しいブランチが作成されたとき、パイプライン完了トリガーブランチ フィルターがこの新しいブランチを含むように変更されますが、新しい分岐フィルターに一致するブランチで最初のパイプラインが完了すると、2 番目のパイプラインはトリガーされません。 これは、Default branch for manual and scheduled builds
ブランチのパイプライン バージョンのブランチ フィルターが新しいブランチと一致しない場合に発生します。 このトリガーの問題を解決するには、次の 2 つのオプションがあります。
- 新しいブランチと一致するように、
Default branch for manual and scheduled builds
ブランチのパイプライン内の分岐フィルターを更新します。 - 手動ビルドとスケジュールされたビルド用の 既定のブランチを、新しいブランチに一致するブランチフィルターが適用されたパイプラインバージョンを持つブランチに更新します。
トリガーの種類の組み合わせ
パイプラインで CI トリガーとパイプライン トリガーの両方を指定すると、CI トリガーのフィルターに一致するプッシュが行われるたびに新しい実行が開始され、パイプライン完了トリガーのフィルターと一致するソース パイプラインの実行が完了することが予想されます。
たとえば、同じリポジトリ内にある A
と B
という名前の 2 つのパイプラインがあり、どちらも CI トリガーを持ち、B
にはパイプライン A
の完了用に構成されたパイプライン完了トリガーがあるとします。 リポジトリにプッシュする場合:
- CI トリガーに基づいて、
A
の新しい実行が開始されます。 - 同時に、CI トリガーに基づいて、
B
の新しい実行が開始されます。 この実行では、パイプラインA
の以前の実行の成果物が使用されます。 A
が完了すると、B
のパイプライン完了トリガーに基づいて、B
の別の実行がトリガーされます。
この例で 2 回の B
の実行をトリガーしないようにするには、その CI トリガー (trigger: none
) またはパイプライン トリガー (pr: none
) を無効にする必要があります。