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

  • [アーティクル]

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

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

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

Note

以前は、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指定されたブランチ内のコードのバージョンが使用されます。

Note

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

分岐フィルター

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

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

Note

ブランチ フィルターが機能しない場合は、プレフィックス 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

Note

パイプライン リソースにも プロパティがあります 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 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 つのパイプラインと B 、同じリポジトリ内にあるとします。どちらも CI トリガーがあり B 、パイプライン完了トリガーがパイプライン Aの完了用に構成されています。 リポジトリにプッシュする場合:

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

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