web-dev-qa-db-ja.com

Azure devopsパイプライン-別のパイプラインでのみトリガーし、コミットしない

要件

したがって、Azure DevOpsには、パイプラインが他のパイプラインをトリガーできるようにするいくつかの新しい機能があり、ここに記載されています。 https://docs.Microsoft.com/en-us/Azure/devops/pipelines/build/triggers？ view = Azure-devops＆tabs = yaml＃pipeline-triggers-1 必要な動作が得られないという事実は別として、すばらしいですね。同じリポジトリに2つのパイプラインが必要です。

  • パイプラインA：自身のリポジトリ外にある他の複数のパイプラインによってのみトリガーされますが、同じプロジェクト内にあります。トリガーされた結果、自身のリポジトリに変更を加え、パイプラインBをトリガーします。
  • Pipleline B：自身のリポジトリへの変更によってのみトリガーされ、トリガーされると先に進み、必要なことをすべて実行します

パイプラインA構文

resources:
    pipelines:
    - pipeline: database
      source: database
      trigger:
        branches:
        - develop
        - release/*
        # The stages filter should work, according to: https://docs.Microsoft.com/en-us/Azure/devops/pipelines/build/triggers?view=Azure-devops&tabs=yaml
        # However, this error occurs when specifying: /Azure-pipelines.yml (Line: 8, Col: 15): Stage filters in pipeline resource database is not supported.
        #stages:
        #- Build
    - pipeline: auth
      source: auth
      trigger:
        branches:
        - develop
        - release/*
    - pipeline: api
      source: api
      trigger:
        branches:
        - develop
        - release/*
    - pipeline: web
      source: web
      trigger:
        branches:
        - develop
        - release/*
  ... multiple triggers - 9 in total
stages:
  ...

現在の動作

パイプラインAは、他のパイプラインによってトリガーされるのではなく、自身のリポジトリへの変更によってのみトリガーされます。それはとにかくそれ自身のリポジトリに変更を加えるので、それは無限ループでそれ自身を引き起こします。

質問/コメント

  • パイプラインAの構文は正しいですか？
  • ドキュメントから：「ただし、2つのパイプラインが異なるリポジトリを使用する場合、トリガーされたパイプラインはデフォルトのブランチからの最新バージョンのコードを使用します。」これは、デフォルトのブランチからのyamlパイプラインがアクティブになることを意味すると想定しています。そして、私たちは本当にその小さな制御を持っていますか？パイプライン宣言でターゲットブランチを指定する方がはるかに良いでしょう。
  • パイプラインをトリガーしたソースブランチをどうにかして取得することは可能ですか？
  • ステージフィルターがドキュメントどおりに機能しないのはなぜですか？
  • パイプラインAで、ループを停止するために、$（Build.TriggeredBy.DefinitionId）を使用して、それが$（System.DefinitionId）と同じかどうかを確認し、同じ場合はビルド手順をスキップしましたが、$（Build.TriggeredBy.DefinitionId ）値がありませんでした
  • 他のパイプラインを動作させることができない場合は、パイプラインAをトリガーすることに傾倒しています。

発見

  • パイプラインの先頭にtrigger: noneを追加すると、リポジトリにコミットが行われたときにパイプラインAが実行されなくなり、現在はまったく実行されません。
  • 別のアカウントの単純化されたパイプラインシナリオで、同じリポジトリ内の2つのパイプラインを使用してトリガーされたビルドを正常に機能させることができました。
    • 実行されたyamlパイプラインファイルは、トリガーパイプラインのコミットと同じブランチにあります
    • チェックアウトされたコードも、トリガーパイプラインのコミットと同じブランチからのものです
    • GUIからの手動パイプライン実行は依存パイプラインをトリガーしません
    • 依存パイプラインがトリガーされ、最初の開始直後にキューに入れられます
    • ブランチの除外を機能させることができませんでした：除外句に関係なくパイプラインがトリガーされました
  • 別のアカウントで簡略化されたパイプラインシナリオを実行し、repo CにパイプラインAを、repo Dに依存パイプラインBを使用して（同じプロジェクト）、パイプラインAを取得してパイプラインをトリガーできませんこれまでのB（私の元のシナリオ）
  • とても嬉しいです:-)パイプラインをサポートし、パイプラインをトリガーできるようにするaz Azure devopsコマンドライン拡張があります。
azure-devopsazure-pipelinesbuild-triggers
5
vipes

トリガーパイプラインからアーティファクトを公開しない場合、トリガーされたパイプラインはトリガーされません。これが機能する最小限の実行可能な製品を作成し、このプロセスをこの answer で説明しました。

0
ccoutinho