次の方法で共有

パイプラインを 1 つずつトリガーする

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

大規模な製品には、相互に依存する複数のコンポーネントがあります。 多くの場合、これらのコンポーネントは個別に構築されます。 アップストリーム コンポーネント (ライブラリなど) が変更された場合、ダウンストリームの依存関係を再構築して再検証する必要があります。

このような状況では、トリガー パイプラインが正常に完了したときにパイプラインを実行するパイプライン トリガーを追加します。

手記

以前は、YAML パイプラインのクラシック エディターに移動し、UI で ビルド完了トリガー を構成しました。 そのモデルは引き続き機能しますが、推奨されなくなりました。 推奨される方法は、YAML ファイル内で直接パイプライン トリガーを指定することです。 クラシック エディターで定義されているビルド完了トリガーには、パイプライン トリガーで対処されているさまざまな欠点があります。 たとえば、ビルド完了トリガーを使用する場合、トリガーされるパイプラインと同じブランチでパイプラインを起動する方法はありません。

パイプライン設定 UI を使用して定義されたトリガーは、YAML トリガーよりも優先されます。 UI のスケジュールされたトリガーの YAML パイプラインからの削除については、「UI の設定で YAML のスケジュールされたトリガーをオーバーライドする」をご覧ください。

パイプライン リソース トリガーを構成する

別のパイプラインの完了時にパイプラインをトリガーするには、パイプライン リソース トリガーを構成します。

次の例では、app-ci パイプラインの実行が完了した後に security-lib-ci という名前のパイプラインが実行されるように、パイプライン リソース トリガーを構成します。

この例には、次の 2 つのパイプラインがあります。

  • security-lib-ci - このパイプラインが最初に実行されます。

    # security-lib-ci YAML pipeline
steps:
- bash: echo "The security-lib-ci pipeline runs first"

  • app-ci - このパイプラインには、app-ci パイプラインの実行が完了するたびに自動的に実行されるように security-lib-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 つのパイプラインが異なるリポジトリを使用する場合、トリガーされるパイプラインでは、パイプライン完了トリガーのに関する Branch の考慮事項に関する説明に従って、 設定で指定されたブランチ内のコードのバージョンが使用されます。

手記

一部のシナリオでは、手動ビルドとスケジュールされたビルドの既定のブランチに refs/heads プレフィックスが含まれていません。 たとえば、既定の分岐は、mainではなく refs/heads/main に設定できます。 このシナリオでは、別のプロジェクトからのトリガーは機能しません。 project をターゲット パイプライン以外の値に設定するときに問題が発生した場合は、その値を別のブランチに変更し、使用する既定のブランチに戻すことで、既定のブランチを更新して refs/heads を含めることができます。

パイプライン完了トリガーの構成は、YAML テンプレートではサポートされていません。 引き続きテンプレートでパイプライン リソースを定義できます。

分岐フィルター

必要に応じて、トリガーの構成時に含めるブランチまたは除外するブランチを指定できます。 分岐フィルターを指定すると、分岐フィルターに一致するソース パイプラインの実行が正常に完了するたびに、新しいパイプラインがトリガーされます。 次の例では、app-ci パイプラインは、security-lib-ciを除く任意の releases/* ブランチで releases/old* が完了した場合に実行されます。

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

親がトリガーされる異なるブランチに対して子パイプラインをトリガーするには、親がトリガーされるすべての分岐フィルターを含めます。 次の例では、app-ciを除き、security-lib-ci ブランチまたはメイン ブランチで releases/* が完了すると、releases/old* パイプラインが実行されます。

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        - main
        exclude:
        - releases/old*

手記

分岐フィルターが機能しない場合は、プレフィックス refs/heads/を使用してみてください。 たとえば、refs/heads/releases/old*の代わりに releases/old*を使用します。

タグ フィルター

手記

パイプライン リソースのタグ フィルター サポートには、Azure DevOps Server 2020 Update 1 以上が必要です。

tags フィルターの trigger プロパティは、どのパイプライン完了イベントがパイプラインをトリガーするかを指定します。 トリガーパイプラインが 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 以上が必要です。

既定では、ターゲット パイプラインは、ソース パイプラインが完了したときにのみトリガーされます。 ソース パイプラインにステージがある場合は、ステージ フィルターを使用して、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.

ブランチに関する考慮事項

手動ビルドおよびスケジュールされたビルド設定()では、パイプライン完了トリガーは、デフォルトブランチを使用します。これは、別のパイプラインの完了の結果としてパイプラインを実行するかどうかを判断する際に、どのブランチのバージョンのYAMLパイプラインのブランチフィルターを評価するかを決定するためです。 既定では、この設定はリポジトリの既定のブランチを指します。

パイプラインが完了すると、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 つのオプションがあります。

トリガーの種類の組み合わせ

パイプラインで CI トリガーとパイプライン トリガーの両方を指定すると、CI トリガーのフィルターに一致するプッシュが行われるたびに新しい実行が開始され、パイプライン完了トリガーのフィルターと一致するソース パイプラインの実行が完了することが予想されます。

たとえば、同じリポジトリ内にある A と B という名前の 2 つのパイプラインがあり、どちらも CI トリガーを持ち、B にはパイプライン Aの完了用に構成されたパイプライン完了トリガーがあるとします。 リポジトリにプッシュする場合:

  • CI トリガーに基づいて、A の新しい実行が開始されます。
  • 同時に、CI トリガーに基づいて、B の新しい実行が開始されます。 この実行では、パイプライン Aの以前の実行の成果物が使用されます。
  • A が完了すると、Bのパイプライン完了トリガーに基づいて、Bの別の実行がトリガーされます。

この例で 2 回の B の実行をトリガーしないようにするには、その CI トリガー (trigger: none) またはパイプライン トリガー (pr: none) を無効にする必要があります。

関連コンテンツ