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

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

この記事では、YAML パイプラインのリソースについて説明します。 リソースとは、パイプラインの外部に存在し、パイプラインによって使用されるものすべてです。 定義したリソースは、パイプラインのどこででも使用できます。

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

リソース スキーマ

YAML のリソースとは、パイプライン、ビルド、リポジトリ、コンテナー、パッケージ、Webhook のソースです。 完全なスキーマ情報については、Azure Pipelines の YAML スキーマ リファレンスのリソース定義を参照してください。

リソースでパイプラインがトリガーされるときに、次の変数が設定されます。

resources.triggeringAlias
resources.triggeringCategory

これらの値が設定されるためには、変数 Build.Reason が ResourceTrigger である必要があります。 リソースがパイプライン実行をトリガーしなかった場合、この値は空になります。

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

成果物を生成するパイプラインがある場合は、 pipelines リソースを定義することでその成果物を使用できます。 pipelines リソースを使用できるのは Azure Pipelines だけです。 パイプライン リソースには、継続的デプロイメント (CD) ワークフローのトリガーを設定できます。

リソース定義での pipeline パイプラインは、パイプライン内で、後でパイプライン リソースを参照するために使用できる一意の値です。 source は、パイプライン成果物を生成したパイプラインの名前です。 スキーマの詳細については、resources.pipelines.pipeline の定義を参照してください。

パイプライン リソース変数を使うときや、成果物をダウンロードするときなどに、パイプラインの他の部分からパイプライン リソースを参照するには、pipeline で定義されているラベルを使います。 パイプライン成果物をダウンロードする別の方法については、「成果物をダウンロードする」を参照してください。

重要

パイプライン リソース トリガーを定義する場合:

• pipeline リソースが現在のパイプライン (self) と同じリポジトリのものであれば、トリガーはイベントが発生した同じブランチおよびコミットに従います。
• パイプライン リソースが別のリポジトリのものであれば、現在のパイプラインは pipeline リソース リポジトリの既定のブランチでトリガーされます。

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

次の例では、同じプロジェクト内のパイプラインの成果物を使用します。

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

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

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

次の例は、単純なトリガーが設定されているパイプライン リソースを示しています。

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

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

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

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

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

次の例では、既定バージョン評価とトリガーに tags フィルターを使用しています。 タグの指定には、AND 演算子が使用されます。

tags は継続的インテグレーション (CI) または CD パイプラインに設定されます。 これらのタグは、Git リポジトリのブランチに設定されるタグとは異なります。

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

パイプライン成果物のバージョン評価

リソース パイプラインの成果物バージョンは、パイプラインのトリガー方法によって異なります。

手動またはスケジュール トリガー

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

指定されたプロパティ	成果物のバージョン
version	指定された実行番号のビルドからの成果物
branch	指定されたブランチで実行された最新ビルドからの成果物
tags リスト	指定されたタグをすべて持つ最新のビルドからの成果物
branch と tags リスト	指定されたタグをすべて持つ、指定のブランチで実行された最新ビルドからの成果物
version と branch	指定した実行番号と指定した分岐を持つビルドからの成果物。
なし	すべてのブランチで最新のビルドからの成果物

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

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

リソース パイプラインの完了トリガー

リソース パイプラインの 1 つが完了したためにパイプラインがトリガーされた場合、成果物バージョンはトリガー パイプラインのバージョンになります。 version、 branch、 tags プロパティの値は無視されます。

指定されたトリガー	結果
branches	リソース パイプラインが include ブランチのいずれかで実行を正常に完了するたびに、新しいパイプライン実行がトリガーされます。
tags	リソース パイプラインで指定のタグがすべて付けられた実行が正常に完了するたびに、新しいパイプライン実行がトリガーされます。
stages	指定された stages がリソース パイプラインで正常に実行されるたびに、新しいパイプライン実行がトリガーされます。
branches、tags、stages	リソース パイプライン実行でブランチ、タグ、ステージのすべての条件が満たされるたびに、新しいパイプライン実行がトリガーされます。
trigger: true	リソース パイプラインの実行が正常に完了するたびに、新しいパイプライン実行がトリガーされます。
なし	リソース パイプラインの実行が正常に完了しても、新しいパイプライン実行はトリガーされません。

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

• releases ブランチのいずれかで、または main ブランチで実行されたとき
• Verified と Signed の両方のタグが付けられているとき
• Production ステージと PreProduction ステージの両方が完了したとき

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

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

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

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

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

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

省略可能な artifact プロパティでは、成果物の名前を指定します。 指定しなかった場合、使用可能なすべての成果物がダウンロードされます。 省略可能な patterns プロパティでは、含めるファイルを表すパターンを定義します。 完全なスキーマ情報については、steps.download の定義を参照してください。

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

パイプライン リソース変数

各実行では、パイプライン リソースのメタデータを、定義済み変数としてすべてのジョブから使用できます。 これらの変数は実行時にのみパイプラインで使用できるものであるため、パイプラインのコンパイル時に評価されるテンプレート式では使用できません。

詳しくは、「定義済み変数としてのパイプライン リソース メタデータ」をご覧ください。 変数の構文の詳細については、「変数の定義」をご参照 ください。

次の例では、myresourcevars パイプライン リソースの定義済みの変数値が返されます。

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 リソースで成果物を使用できます。 build リソースは、Jenkins、TeamCity、CircleCI など、任意の外部 CI システムから取得できます。

builds はカテゴリは拡張可能です。 ビルド サービスから成果物を使用する拡張機能を作成し、builds の一部として新しい種類のサービスを導入できます。

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

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

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

重要

トリガーは、Azure DevOps が Jenkins サーバーと通信できるホステッド Jenkins に対してのみサポートされます。

downloadBuild タスク

build リソース成果物は、ジョブとデプロイ ジョブでは自動的にダウンロードされません。 build リソースからの成果物をジョブの一部として使用するには、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 パイプラインでは、リポジトリの種類の値として、git、github、githubenterprise、および bitbucket がサポートされています。

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

Type	name の値	例
type: git	同じプロジェクトまたは同じ組織内の別のリポジトリ。	同じプロジェクト: name: otherRepo 同じ組織内の別のプロジェクト: name: otherProject/otherRepo。
type: github	GitHub リポジトリの完全な名前 (ユーザーまたは組織を含む)。	name: Microsoft/vscode
type: githubenterprise	GitHub Enterprise リポジトリの完全な名前 (ユーザーまたは組織を含む)。	name: Microsoft/vscode
type: bitbucket	Bitbucket Cloud リポジトリの完全な名前 (ユーザーまたは組織を含む)。	name: MyBitbucket/vscode

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

各実行では、パイプライン リソースに関する以下のメタデータを、定義済み変数の形式ですべてのジョブから使用できます。 <Alias> は、ユーザーがリポジトリ リソースに対して指定する識別子です。

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

次の例では、common というエイリアスを持つリポジトリ リソースがあり、リポジトリ リソース変数には resources.repositories.common.* を使用してアクセスしています。

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 の定義を参照してください。

詳しくは、「パイプラインで複数のリポジトリをチェックアウトする」をご覧ください。

コンテナー リソース定義

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

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

パイプラインの一部として Docker レジストリのイメージを使用する必要がある場合は、汎用コンテナー リソースを定義できます。 type キーワードは必要ありません。 次に例を示します。

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

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

Note

すべてのイメージ タグでコンテナー トリガーを有効にするための enabled: 'true' 構文は、他のリソース トリガーの構文とは異なります。 必ず、リソースに対して適切な構文を使用してください。

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* 

Note

トリガーの評価は、既定のブランチのみで行われます。 正しい既定のブランチを設定するか、YAML ファイルを現在の既定のブランチにマージしてください。 パイプラインの既定のブランチを変更する方法の詳細については、「パイプラインの既定のブランチ」を参照してください。

コンテナー リソース変数

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

コンテナー リソース変数は、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)

パッケージ リソース定義

YAML パイプラインのリソースとして、NuGet パッケージと npm GitHub パッケージを使用できます。 新しいパッケージ バージョンがリリースされたときに自動パイプライン トリガーを有効にするには、trigger プロパティを true に設定します。

package リソースを定義するときは、< プロパティにパッケージ >Repository</>Namename を指定し、パッケージのtype を NuGet または npm に設定します。 GitHub パッケージを使用するには、個人用アクセス トークン (PAT) ベースの認証を使用し、PAT を使用する GitHub サービス接続を作成します。

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

既定では、パッケージはジョブに自動的にダウンロードされません。 ダウンロードするには、getPackage を使用します。

次の例では、 という名前の GitHub npm パッケージに対する pat-contoso という名前の contosoを使用しています。 詳しくは、 GitHub パッケージに関するページをご覧ください。

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

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Webhook リソース定義

Note

Webhook は、Azure DevOps Server 2020.1 でリリースされました。

パイプライン、コンテナー、ビルド、パッケージのリソースでは、成果物を使用し、自動トリガーを有効にすることができます。 ただし、これらのリソースを使用して、外部のイベントやサービスに基づいてデプロイを自動化することはできません。

YAML パイプラインの webhooks リソースを使用すると、パイプラインを GitHub、GitHub Enterprise、Nexus、Artifactory などの外部サービスと統合してワークフローを自動化できます。 Webhook を使用して外部イベントをサブスクライブし、そのイベントを使用してパイプラインをトリガーできます。

Webhook は、パイプライン、ビルド、コンテナー、パッケージなどのファースト クラス リソースでサポートされていない外部 Webhook イベントに基づいて、ワークフローを自動化します。 また、Azure DevOps がプロセス内を認識できないオンプレミス サービスの場合は、サービスで Webhook を構成し、パイプラインを自動的にトリガーできます。

Webhook イベントをサブスクライブするには、パイプラインで Webhook リソースを定義し、そのリソースから着信 Webhook サービス接続をポイントします。 また、JSON ペイロード データに基づいて Webhook リソースでさらにフィルターを定義し、各パイプライン用にトリガーをカスタマイズすることもできます。

着信 Webhook サービス接続が Webhook イベントを受信するたびに、Webhook イベントをサブスクライブしているすべてのパイプラインについて新しい実行がトリガーされます。 ${{ parameters.<WebhookAlias>.<JSONPath>}} という形式を使用することにより、ジョブ内で JSON ペイロード データを変数として使用できます。

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

次の例では、Webhook リソースを定義しています。

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Webhook トリガー

Webhook トリガーを構成するには、まず外部サービスに Webhook を設定し、次の情報を指定します。

• 要求 URL: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
• シークレット (省略可能): JSONペイロードを保護する必要がある場合は、シークレット値を指定します。

次に、新しい着信 Webhook サービス接続を作成します。 このサービス接続の種類には、次の情報を定義します。

• WebHook 名: 外部サービスで作成された Webhook と同じです。
• シークレット (省略可能): 着信要求の検証用にペイロードの HMAC-SHA1 ハッシュを検証するために使用されます。 Webhook の作成時にシークレットを使った場合は、同じシークレットを指定する必要があります。
• HTTP ヘッダー: 要求検証用のペイロードの HMAC-SHA1 ハッシュ値を含む、要求内の HTTP ヘッダー。 たとえば、GitHub 要求ヘッダーは X-Hub-Signature です。

Webhook を使用してパイプラインをトリガーするには、POST に対する https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview 要求を行う必要があります。 このエンドポイントは一般公開されており、承認は必要ありません。 要求の本文は、次の例のようになります。

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

Note

Webhook の要求本文からデータにアクセスすると、YAML が正しくなくなる可能性があります。 たとえば、パイプライン ステップ - script: echo ${{ parameters.WebHook.resource.message }} では JSON メッセージ全体が取得され、無効な YAML が生成されます。 生成された YAML が無効になったため、この Webhook を介してトリガーされるパイプラインは実行されません。

次のスニペットは、Webhook フィルターを使用する別の例を示しています。

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}}

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

CD YAML パイプラインを手動でトリガーすると、Azure Pipelines は、提供された入力に基づいて、パイプラインで定義されているリソースの既定のバージョンを自動的に評価します。 ただし、スケジュールされたトリガーの既定のバージョンを評価する場合や、手動でバージョンを選択していない場合、Azure Pipelines では、正常に完了した CI 実行のみが考慮されます。

実行を作成するときには、リソース バージョン ピッカーを使用して別のバージョンを手動で選択できます。 リソース バージョン ピッカーは、パイプライン、ビルド、リポジトリ、コンテナー、パッケージの各リソースでサポートされています。

パイプライン リソースの場合は、すべてのブランチで利用可能なすべての実行を表示し、パイプライン番号またはブランチに基づいて検索し、成功、失敗、または進行中の実行を選択できます。 この柔軟性により、実行によって必要な成果物がすべて生成されることが確実な場合に、CD パイプラインを実行できます。 CI 実行が完了するまで待機する必要も、無関係なステージの失敗のために CI 実行を再実行する必要もありません。

リソース バージョン ピッカーを使用するには、[パイプラインの実行] ペインで [リソース] を選択し、リソースを選択して、使用可能なバージョンの一覧から特定のバージョンを選択します。

GitHub パッケージなど、利用可能なバージョンを取得できないリソースの場合、バージョン ピッカーにはテキスト フィールドが用意されており、実行時に選択するバージョンを入力できます。

YAML パイプラインでのリソース承認

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

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

• パイプラインを作成すると、それらのリソースに対するユーザー ロールを持っていれば、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 パイプライン内の関連する CD パイプライン情報

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

リソース トリガーに関する問題

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

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

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

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

よく寄せられる質問

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

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 スキーマ リファレンス