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

  • [アーティクル]

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

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

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

注意

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

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

注意

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

分岐フィルター

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

注意

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

タグ フィルター

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

ステージ フィルター

フィルターを使用して、トリガーするパイプラインの 1 つ以上のステージが完了したときにパイプラインを stages トリガーできます。 複数のステージを指定すると、一覧表示されているすべてのステージが完了すると、トリガーされたパイプラインが実行されます。

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 ブランチ の値を確認します。 そのブランチのバージョンのパイプラインのブランチ フィルターは、パイプライン完了トリガーがパイプラインの実行を開始するかどうかを判断するために使用されます。 既定では、 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、同じリポジトリ内にある 2 つのパイプラインには CI トリガーがありB、パイプラインの完了用に構成されたパイプライン完了トリガーがあるとしますA。B リポジトリにプッシュする場合:

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

この例で 2 回の実行を B トリガーしないようにするには、その CI トリガーまたはパイプライン トリガーを削除する必要があります。