YAML パイプラインのリソース

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

この記事では、YAML パイプラインのリソースについて説明します。 リソースとは、パイプラインの外部に存在するパイプラインで使用されるものです。 YAML パイプライン内のリソースには、他のパイプライン、ビルド、コンテナー、パッケージ、リポジトリ、または Webhook を使用できます。

定義したリソースは、パイプラインのどこででも使用できます。 詳細と例については、「 リソース定義」を参照してください。

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

リソース定義で プロパティを設定することで、リソースの状態を使用してパイプラインを自動的にtriggerできます。 パイプライン resources.triggeringAlias 変数と resources.triggeringCategory 変数は、リソース名とカテゴリに設定されます。 Build.Reason変数が ResourceTrigger に設定されていない限り、これらの変数は空です。

リソースを使用すると、バージョン、成果物、関連するコミット、作業項目など、パイプラインで使用されるサービスの完全な 追跡可能性 を実現できます。 リソースのトリガー イベントをサブスクライブする場合は、DevOps ワークフローを完全に自動化できます。

リソース承認

リソースは、パイプラインで使用することが承認されている必要があります。 リソース所有者は、リソースにアクセスできるユーザーとパイプラインを制御します。 YAML パイプラインでのリソースの使用を承認する方法はいくつかあります。

• リソースの管理設定を使用して、 すべてのパイプラインにアクセス許可を付与します。 たとえば、[ Pipelines>Library ] ページでセキュリティで保護されたファイルと変数グループを管理し、 Project 設定>Pipelines でエージェント プールとサービス接続を管理できます。 この承認は、テスト リソースなど、制限する必要のないリソースに便利です。

• プロジェクトのエージェント プール セキュリティ ロールに少なくともユーザー ロールがあることを確認します。 作成した YAML パイプラインには、 ユーザー ロールがあるリソースを使用する権限が自動的に付与されます。

• リソース定義を YAML パイプラインに追加しても、 Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for useなどのエラーでビルドが失敗する場合は、リソースに少なくとも ユーザー ロールがあることを確認してください。 その後、失敗したビルドでリソースを承認するオプションを選択できます。 リソースが承認されたら、新しいビルドを開始できます。

リソースの承認チェック

承認チェックとテンプレートを使用して、リソースの使用を手動で制御できます。 必要なテンプレート承認チェックを使用すると、特定の YAML テンプレートから拡張するために、特定のリソースまたは環境を使用する任意のパイプラインを要求できます。

必要なテンプレート承認を設定すると、リソースが特定の条件下でのみ使用されるようにすることで、セキュリティが強化されます。 詳細については、「 セキュリティにテンプレートを使用する」を参照してください。

手動リソース バージョン ピッカー

Azure Pipelines は、リソース定義に基づいてリソースの既定のバージョンを評価します。 スケジュールされた実行の場合、または実行を手動で選択しない場合は手動実行の場合、Azure Pipelines では、既定のリソース バージョンを評価するために正常に完了した継続的インテグレーション (CI) 実行のみが考慮されます。

手動リソース バージョン ピッカーを使用して、YAML 継続的デプロイ (CD) パイプラインを手動でトリガーするときに、さまざまなリソース バージョンを選択できます。 リソース バージョン ピッカーは、パイプライン、ビルド、リポジトリ、コンテナー、パッケージの各リソースでサポートされています。

pipelineリソースの場合、手動バージョン ピッカーを使用すると、すべてのブランチで使用可能なすべての実行を表示し、パイプライン番号または分岐に基づいて実行を検索し、成功、失敗、または進行中の実行を選択できます。

CD パイプラインを実行する前に、CI の実行が完了するまで待機したり、関連のないエラーが原因で再実行したりする必要はありません。 必要な成果物が生成されたことを知っている任意の実行を柔軟に選択できます。

リソース バージョン ピッカーを使用するには、[パイプラインの実行] ウィンドウで [リソース] を選択し、リソースを選択し、使用可能なバージョンの一覧から特定のバージョンを選択します。 GitHub パッケージなど、使用可能なバージョンをフェッチできないリソースの場合は、テキスト フィールドに目的のバージョンを入力できます。

リソース定義

YAML パイプライン リソースは次のようになります。

• その他のパイプライン
• ビルド
• コンテナー
• パッケージ
• リポジトリ、または
• Webhooks。

次のセクションでは、YAML パイプライン リソース カテゴリの定義と例を示します。 完全なスキーマ情報については、Azure Pipelines の YAML スキーマ リファレンスのリソース定義を参照してください。

Pipelines リソース

CD ワークフローのpipelineとして CI リソースを使用できます。 パイプラインから pipeline リソースを参照して 成果物をダウンロード したり、 パイプライン リソース変数を使用したりすることもできます。 pipelines リソースを使用できるのは Azure Pipelines だけです。

pipelines リソース定義で、次の操作を行います。

• pipeline は、パイプライン リソースを参照するために使用する一意の名前です。
• source は、パイプライン成果物を生成したパイプラインの名前です。

完全なスキーマ情報については、 resources.pipelines.pipeline の定義を参照してください。

パイプライン リソース定義の例

次のリソース定義の例では、同じ Azure DevOps プロジェクト内のパイプラインから成果物を使用します。

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

別のプロジェクトのパイプラインを指定するには、リソース定義に project 名を含めます。 次の例では、パイプラインが手動またはスケジュールによってトリガーされたときに、 branch を使用して既定のバージョンを解決します。 ブランチの入力にワイルドカードを使用することはできません。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

リソース バージョンの評価

Azure Pipelines は、リソース定義に基づいてリソースの既定のバージョンを評価します。 パイプラインの既定のリソース成果物バージョンは、パイプラインが手動で実行されるかスケジュールに従って実行されるか、リソース実行の結果に基づいて トリガー されるかによって異なります。

手動またはスケジュールされたパイプライン実行の場合、version リソース定義のbranch、tags、およびpipelineプロパティの値によって成果物のバージョンが定義されます。 branch入力にはワイルドカードを使用できません。tagsプロパティでは、AND演算子を使用します。

スケジュールされた実行の場合、またはバージョン ピッカーを使用しない場合は手動実行の場合、Azure Pipelines では、既定のリソース バージョンを評価するときに、正常に完了した継続的インテグレーション (CI) の実行のみが考慮されます。 手動実行の場合は、 手動バージョン ピッカーを使用して、定義されたバージョンをオーバーライドできます。

次の表 pipeline リソース定義のプロパティと、指定した成果物のバージョンを示します。

次の pipeline リソース定義では、パイプラインが手動でスケジュールまたはトリガーされたときに、 branch プロパティと tags プロパティを使用して既定のバージョンを評価します。 myCIAlias成果物のバージョンは、mainタグとProduction タグを持つPreProduction ブランチでの最新のビルド実行です。

resources:
  pipelines:
  - pipeline: myCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

パイプライン リソース トリガー

リソース実行の結果をトリガーするパイプライン実行の場合、リソース定義の trigger プロパティ設定によって、既定のリソース成果物のバージョンが決まります。 pipeline リソースをトリガーとして使用して現在のパイプラインを実行するには、trigger プロパティを設定する必要があります。 trigger プロパティを含めない場合、リソースの実行は現在のパイプラインの実行をトリガーしません。

trigger リソース定義のpipeline値に基づいてパイプラインがトリガーされると、リソース定義全体のversion、branch、およびtagsプロパティの値は無視されます。 triggerプロパティによって成果物のバージョンが決まります。

次の表では、 trigger プロパティがトリガーの動作に与える影響について説明します。

次の例は、単純な triggerを使用したパイプライン リソース定義を示しています。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger: true

次の例は、ブランチの条件を含むパイプライン リソース trigger を示しています。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

次の例では、 stages フィルターを使用して CD パイプラインのトリガー条件を評価します。 トリガーstagesAND演算子を使用します。 CD パイプラインは、一覧表示されているすべてのステージが正常に完了するとトリガーされます。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Fabrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

次の例では、既定のバージョン評価とトリガーに tags フィルターを使用します。 trigger タグでは、AND演算子を使用します。 tagsリソース定義で設定されたpipelineは、Git リポジトリ内のブランチに設定されているタグとは異なります。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

下のパイプラインは、SmartHotel-CI リソース パイプラインが次の状態になるたびに実行されます。

• releases ブランチまたは main ブランチで実行されます。
• VerifiedとSignedの両方でタグ付けされます。
• ProductionとPreProductionの両方のステージを完了します。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

パイプライン成果物のダウンロード

YAML パイプラインの download ステップを使用して、現在の実行または別の pipeline リソースに関連付けられている成果物をダウンロードできます。

成果物は、デプロイ ジョブでのみ自動的にダウンロードされます。 現在のパイプラインとそのすべての pipeline リソースからのすべての成果物が自動的にダウンロードされ、各デプロイ ジョブの開始時に使用できます。 この動作をオーバーライドするには、 download を none に設定するか、別の pipeline リソース識別子を指定します。

通常のビルド ジョブでは、成果物は自動的にダウンロードされません。 必要なときは、明示的に download を使います。

downloadの手順では、オプションの artifact プロパティでアーティファクト名を指定します。 指定しない場合は、使用可能なすべての成果物がダウンロードされます。

オプションの patterns プロパティは、ダウンロードするファイルを表すパターンを定義します。 完全なスキーマ情報については、 steps.download の定義を参照してください。

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

pipeline リソースからの成果物が $(PIPELINE) にダウンロードされます。WORKSPACE)/<pipeline-identifier>/<artifact-identifier> フォルダー。 詳細については、「パイプライン成果物を発行してダウンロードする」を参照してください。 パイプライン成果物をダウンロードする別の方法については、「成果物をダウンロードする」を参照してください。

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

リソースをビルドする

成果物を生成する CI ビルド システムがある場合は、 builds リソースで成果物を使用できます。

builds はカテゴリは拡張可能です。 build リソースは、Jenkins、TeamCity、CircleCI など、任意の外部 CI システムから取得できます。 buildsを使用して、ビルド サービスから成果物を使用する拡張機能を記述したり、新しい種類のサービスを導入したりできます。

build 定義では、version の既定値は最新の成功したビルドに設定されます。 必要に応じて、 trigger を明示的に設定する必要があります。 完全なスキーマ情報については、 resources.builds.build の定義を参照してください。

次の例では、Jenkins はリソースの種類です。

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

downloadBuild タスク

build リソース成果物は、jobs/deploy-jobs に自動的にダウンロードされません。 build リソースからの成果物をジョブの一部として使用するには、downloadBuild タスクを明示的に追加する必要があります。 各デプロイまたはジョブのダウンロード動作をカスタマイズできます。

downloadBuild タスクは、ランタイムが定義するリソースの種類build対応するダウンロード タスクに自動的に解決されます。 build リソースからの成果物が $(PIPELINE) にダウンロードされます。WORKSPACE)/<build-identifier>/ フォルダー。

downloadBuild 定義では、成果物のダウンロード元のリソースを指定します。 省略可能な artifact プロパティでは、ダウンロードする成果物を指定します。 指定しない場合は、リソースに関連付けられているすべての成果物がダウンロードされます。

省略可能な patterns プロパティでは、ダウンロードする minimatch パスまたは minimatch パスの一覧を定義します。 空白の場合、アーティファクト全体がダウンロードされます。 次の例では、 *.zip ファイルのみをダウンロードします。

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

完全なスキーマ情報については、 steps.downloadBuild の 定義を参照してください。

リポジトリ リソース

次の場合は、 repository キーワードを使用して、システムに外部リポジトリについて通知します。

• パイプラインには 、別のリポジトリにテンプレートがあります。
• サービス接続を必要とするリポジトリで マルチリポジトリ チェックアウト を使用する場合。

次に例を示します。

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

スキーマの詳細については、 resources.repositories.repository の定義を参照してください。

リポジトリ リソースの種類

Azure Pipelines では、 git、 github、 githubenterprise、および bitbucket リポジトリの種類がサポートされています。

• 種類 git は、Azure Repos Git リポジトリのことです。
• GitHub Enterprise リポジトリでは、承認のために GitHub Enterprise サービス接続 が必要です。
• Bitbucket Cloud リポジトリでは、承認のために Bitbucket Cloud サービス接続 が必要です。

次の表では、 repository リソースの種類について説明します。

リポジトリ リソースの変数

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url
resources.repositories.<alias>.version

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

リポジトリに対するチェックアウト キーワード

repository リソースからのリポジトリは、ジョブ内では自動的に同期されません。 checkout キーワードを使用して、repository リソースで定義されているリポジトリをフェッチできます。 詳しくは、「パイプラインで複数のリポジトリをチェックアウトする」をご覧ください。 完全なスキーマ情報については、 steps.checkout の定義を参照してください。

コンテナー リソース

containers リソースを使用して、CI/CD パイプラインでコンテナー イメージを使用できます。 container リソースには、パブリックまたはプライベートの Docker レジストリまたは Azure Container Registry インスタンス を使用できます。

ジョブの一部として汎用コンテナー リソース イメージを使用することも、 コンテナー ジョブで使用することもできます。 パイプラインで 1 つ以上のサービスのサポートが必要な場合は、 サービス コンテナーを作成して接続する必要もあります。 ボリュームを使用して、サービス間 で データを共有できます。

Docker レジストリからイメージを使用する必要がある場合は、 type キーワードを使用せずに汎用コンテナー リソースを定義できます。 次に例を示します。

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp 

完全なスキーマ情報については、 resources.containers.container の定義を参照してください。

Azure Container Registry リソースの種類

Azure Container Registry イメージを使用するには、ファーストクラス コンテナー リソースの種類である acr を使用できます。 このリソースの種類をジョブで使用し、自動パイプライン トリガーを有効にすることができます。

自動パイプライン トリガーを使用するには、Azure Container Registry 共同作成者 または 所有者 のアクセス許可が必要です。 詳細については、「Azure Container Registry のロールとアクセス許可」をご覧ください。

acr リソースの種類を使用するには、Azure コンテナー レジストリの azureSubscription、resourceGroup、および repository の値を指定する必要があります。 次に例を示します。

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production* 

コンテナー リソース変数

コンテナーをリソースとして定義すると、コンテナー イメージ メタデータが変数としてパイプラインに渡されます。 イメージ、レジストリ、接続の詳細などの情報には、コンテナー デプロイ タスクで使用されるすべてのジョブからアクセスできます。

コンテナー リソース変数は、Docker とAzure Container Registry で動作します。 ローカル イメージ コンテナーにコンテナー リソース変数を使用することはできません。 ___location変数は、acr コンテナー リソースの種類にのみ適用されます。

次の例では、 という名前の arm-connectionを使用しています。 詳しくは、 Azure のコンテナー レジストリ、リポジトリ、イメージに関する記事をご覧ください。

resources:
  containers:
  - container: mycontainer
    type: acr
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.___location)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

steps:  
- script: echo ${{ parameters.myWebHookResource.resource.message.title }}

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

追跡可能性

パイプラインまたはデプロイ ジョブのレベルで使われるすべてのリソースについて、Azure Pipelines では完全な追跡可能性が提供されています。 Azure Pipelines には、リソースを使用するすべてのパイプライン実行に関する次の情報が表示されます。

• リソースによってパイプラインがトリガーされた場合は、パイプラインをトリガーしたリソース。
• リソースのバージョンと消費された成果物。
• 各リソースに関連付けられているコミット。
• 各リソースに関連付けられている作業項目。

CI パイプラインの関連 CD パイプライン情報

エンドツーエンドの追跡可能性を提供するために、 pipelines リソースを介して特定の CI パイプラインを使用した CD パイプラインを追跡できます。 他のパイプラインが CI パイプラインを使用した場合は、[実行] ビューに [関連付けられたパイプライン] タブが表示されます。 このビューには、CI パイプラインとその成果物を使用したすべての CD YAML パイプライン実行が表示されます。

環境の追跡可能性

パイプラインが環境にデプロイされると、使用したリソースの一覧と、関連するコミットと作業項目を確認できます。

FAQ

パイプライン リソース、ダウンロード ショートカット、パイプライン成果物のダウンロード タスクは、どのようなときに使用すればよいのですか?

pipelines リソースを使うのは、CI パイプラインから成果物を使用し、自動トリガーを構成するための方法です。 リソースにより、使われているバージョン、成果物、コミット、作業項目が表示され、プロセスの内容を完全に確認できます。 パイプライン リソースを定義すると、関連する成果物がデプロイ ジョブに自動的にダウンロードされます。

download ショートカットを使用して、ビルド ジョブで成果物をダウンロードすることも、デプロイ ジョブでダウンロード動作をオーバーライドすることもできます。 詳細については、 steps.download の定義を参照してください。

パイプライン アーティファクトのダウンロード タスクでは追跡可能性やトリガーが提供されませんが、このタスクを直接使用する方が適切な場合もあります。 たとえば、ビルドからの成果物をダウンロードする必要があるスクリプト タスクが別のテンプレートに格納されている場合があります。 または、パイプライン リソースをテンプレートに追加することが望ましくない場合もあります。 依存関係を回避するには、パイプライン成果物のダウンロード タスクを使って、すべてのビルド情報をタスクに渡すことができます。

Docker Hub のイメージが更新されたときに、パイプライン実行をトリガーするにはどうすればよいですか?

コンテナー リソース トリガーは、YAML パイプライン用の Docker Hub では使用できないため、 クラシック リリース パイプラインを設定する必要があります。

1. 新しい Docker Hub サービス接続を作成します。
2. クラシック リリース パイプラインを作成し、Docker Hub 成果物を追加します。 サービス接続を設定し、名前空間、リポジトリ、バージョン、およびソース エイリアスを選択します。
3. トリガーを選んで、継続的デプロイ トリガーを [有効] に切り替えます。 選択したリポジトリに対して Docker プッシュが行われるたびに、リリースが作成されます。
4. 新しいステージとジョブを作成します。 Docker ログインと Bash という 2 つのタスクを追加します。
   • Docker タスクには login アクションがあり、ユーザーを Docker Hub にサインインさせます。
   • Bash タスクは docker pull <hub-user>/<repo-name>[:<tag>] を実行します。

作成した Webhook を検証してトラブルシューティングするにはどうすればよいですか?

1. サービス接続を作成します。

2. サービス接続を参照し、 webhooks セクションで Webhook の名前を指定します。

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. パイプラインを実行する。 Webhook は、組織の分散タスクとして Azure に作成されます。

4. 本文で POSTへの有効な JSON を使って、 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> API 呼び出しを実行します。 200 状態コード応答を受け取る場合、Webhook はパイプラインで使用できる状態になっています。

500 状態コード応答とエラー Cannot find webhook for the given webHookId ... が表示される場合は、既定のブランチではないブランチにコードが存在する可能性があります。 この問題に対処するには、次の手順を実行します。

1. パイプライン ページの [編集] を選択します。
2. [その他の操作] メニューから、[トリガー] を選択します。
3. [YAML] タブを選択し、[ソースの取得] を選択します。
4. [手動のビルドとスケジュールされたビルドの既定のブランチ] の下で、機能ブランチを更新します。
5. [保存して & キューに登録] を選択します。
6. このパイプラインが正常に実行した後、本文で POSTへの有効な JSON を使って https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> API 呼び出しを実行します。 これで、200 状態コード応答を受け取るようになるはずです。

リソーストリガーが機能しなかったのはなぜですか?

リソース トリガーの実行が失敗する原因には、次のようなものがあります。

• 指定されたサービス接続のソースが無効です。
• トリガーが構成されていないか、トリガーに構文エラーがあります。
• トリガーの条件が適合しない。

パイプライン トリガーの実行が失敗となった理由を確認するには、パイプライン定義のページで [トリガーの問題] メニュー項目を選択します。 トリガーの問題 は、リポジトリ リソースでは使用できません。

[トリガーの問題]ページには、トリガーが失敗となった理由を示すエラー メッセージと警告メッセージが表示されます。

関連するコンテンツ

• Azure Pipelines のリソースについて
• 変数の定義
• 変数グループの追加と使用
• 環境を作成してターゲットにする
• YAML パイプライン エディターを使用する
• YAML スキーマ リファレンス