次の方法で共有

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

  • [アーティクル]

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

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

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

注意

以前は、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 ポータルから、パイプラインのランディング ページなど、いくつかの場所で取得できます。 既定では、パイプラインにはパイプラインを含むリポジトリの名前が付けられます。 パイプラインの名前を更新するには、「パイプラインの設定」を参照してください。 パイプラインがフォルダーに含まれている場合は、先頭 \ を含むフォルダー名 (たとえば \security pipelines\security-lib-ci) を含めます。
  • project: FabrikamProject - トリガーするパイプラインが別の Azure DevOps プロジェクトにある場合は、プロジェクト名を指定する必要があります。 ソース パイプラインとトリガーされるパイプラインの両方が同じプロジェクト内にある場合、このプロパティは省略可能です。 この値を指定してもパイプラインがトリガーしない場合は、このセクションの最後にある注意を参照してください。
  • trigger: true - ソース パイプラインの任意のバージョンが完了したときにパイプラインをトリガーするには、この構文を使用します。 この記事の後続のセクションでは、完了時に実行をトリガーするソース パイプラインのバージョンをフィルター処理する方法について説明します。 フィルターを指定する場合、実行をトリガーするには、ソース パイプラインの実行がすべてのフィルターと一致する必要があります。

トリガーするパイプラインとトリガーされるパイプラインが同じリポジトリを使用する場合、両方のパイプラインは、他方をトリガーするときに同じコミットを使用して実行されます。 これは、最初のパイプラインでコードをビルドし、2 番目のパイプラインでそれをテストする場合に役立ちます。 ただし、2 つのパイプラインで異なるリポジトリが使用される場合には、「パイプライン完了トリガーの分岐に関する考慮事項」で説明されているように、トリガーされるパイプラインでは、Default branch for manual and scheduled builds 設定で指定されたブランチ内のコードのバージョンが使用されます。

注意

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

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

ブランチ フィルター

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

Note

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

タグ フィルター

パイプライン完了イベントがパイプラインをトリガーできる 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 プロパティは、パイプラインが手動またはスケジュールされたトリガーによってトリガーされたときに、成果物を取得するパイプライン実行を決定するために使用されます。 詳細については、「リソース: パイプライン」および「成果物バージョンの評価」を参照してください。

ステージ フィルター

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 つのオプションがあります。

  • 新しいブランチと一致するように、Default branch for manual and scheduled builds ブランチ内のパイプラインのブランチ フィルターを更新します。
  • [手動ビルドとスケジュールされたビルドの既定のブランチ] 設定を、新しいブランチに一致するブランチ フィルターを使用して、パイプラインのバージョンを持つブランチに更新します。

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

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

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

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

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