web-dev-qa-db-ja.com

YAMLを使用してパイプラインをトリガーするAzure Pipeline

YAMLを使用して別のパイプラインが完了したときに、Azureパイプラインをトリガーしようとしています。 documentation があり、パイプラインリソースを追加できることを示しています。

resources:   # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the pipeline resource
    connection: string  # service connection for pipelines from other Azure DevOps organizations
    project: string # project for the source; optional for current project
    source: string  # source defintion of the pipeline
    version: string  # the pipeline run number to pick the artifact, defaults to Latest pipeline successful across all stages
    branch: string  # branch to pick the artiafct, optional; defaults to master branch
    tags: string # picks the artifacts on from the pipeline with given tag, optional; defaults to no tags

ただし、「ソース」の意味を理解できませんでした。たとえば、myproject.myprogramというパイプラインがあります。

resources:
  pipelines:
  - pipeline: myproject.myprogram
    source: XXXXXXXX

さらに、これに基づいてトリガーに基づいてビルドする方法は不明です。

これはウェブGUIから実行できることは知っていますが、YAMLから実行できるはずです。

azureazure-devopsazure-pipelines
8
Alex Kaszynski

別のAzure公式から1つのパイプラインをトリガーする場合 docs 以下のソリューションを提案します。つまり、パイプライントリガーを使用します

resources:
  pipelines:
  - pipeline: RELEASE_PIPELINE // any arbitrary name
    source: PIPELINE_NAME.    // name of the pipeline shown on Azure UI portal
    trigger:
    branches:
      include:
        - dummy_branch        // name of branch on which pipeline need to trigger

しかし実際には、2つのパイプラインAとBがあり、Aが終了したときにBをトリガーするとします。したがって、このシナリオでは、コミット（Aと並行）を実行するときにBが2回実行され、Aが終了した後に2回実行されます。

したがって、これを回避するには2回のパイプライン実行の問題が次の解決策に従ってください

trigger: none // add this trigger value to none 
resources:
  pipelines:
  - pipeline: RELEASE_PIPELINE // any arbitrary name
    source: PIPELINE_NAME.    // name of the pipeline shown on Azure UI portal
    trigger:
    branches:
      include:
        - dummy_branch        // name of branch on which pipeline need to trigger

trigger：noneを追加することにより、2番目のパイプラインはコミットの開始時にトリガーされず、最初のジョブの終了時にのみトリガーされます。

それがお役に立てば幸いです。

2
Sunny Goel

リソースはビルド完了トリガー用ではありません。 docs によると、ビルド完了トリガーはnotまだYAML構文でサポートされています。

YAMLパイプラインを作成したら、クラシックエディターに移動して（settingsまたはvariablesをクリック）、トリガーを作成できます。

編集：

次に、「トリガー」をクリックする必要があります。

enter image description here

その後：

enter image description here

2番目の編集：

マイクロソフトはこの機能もYAMLに追加しました:)参照 ここ ：

# this is being defined in app-ci pipeline
resources:
  pipelines:
  - pipeline: security-lib
    source: security-lib-ci
    trigger: 
      branches:
      - releases/*
      - master

上記の例では、app-ciとsecurity-lib-ciの2つのパイプラインがあります。新しいバージョンのセキュリティライブラリがマスターまたはリリースブランチに組み込まれるたびに、app-ciパイプラインが自動的に実行されるようにします。

6
Shayki Abramczyk

Microsoft documentation は、YAMLが推奨されるアプローチであると述べています。したがって、ビルドトリガーオプションを使用する代わりに、少し混乱するYAMLトリガーを理解しましょう。次のタグは、元の質問から機能し、少し簡単なドキュメントで機能します。

resources:
  pipelines:
  - pipeline: aUniqueNameHereForLocalReferenceCanBeAnything
    project: projectNameNOTtheGUID
    source: nameOfTheOtherPipelineNotTheDefinitionId
    trigger:
      branches:
        include:
        - master
        - AnyOtherBranch

Microsoftのドキュメントはわかりにくく、IDが多数あります。ときどきプロジェクトGUID=プロジェクト名が必要な場合があります。パイプライン名が必要な場合とパイプライン定義IDが必要な場合があります。しかし、変数（プロジェクトとパイプラインそれに加えて、彼らは最良の方法を使用するのが試行錯誤することであると推測することを容易にしない文書を書いています。

他の場所での混乱を避けるために、パイプライン内の別の場所で、値が異なる同じ変数を参照している例を挙げます。 DownloadArtifactタスクでは、以下に示すように、プロジェクトGUIDおよびパイプライン定義IDを使用する必要があります。

- task: DownloadPipelineArtifact@2
      inputs:
        source: specific (a literal constant value not the pipeline name)
        project: projectGUIDNOTtheProjectName
        pipeline: numericDefinitionIdOfPipelineNotPipelineNameOrUniqueRef
        runVersion: 'latest'

同じ変数を別の方法で使用した方法を見てください。どちらもパイプラインと、私の場合はまったく同じパイプラインを参照しています。これは混乱を招く可能性があり、次の問題に出くわすことを避けるために、明確にするためにここに示します。

4
SijuMathew