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

[アーティクル]
07/02/2024

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` リスト	指定されたすべてのタグを持つ、指定したブランチで実行された最新のビルドからの成果物
なし	すべてのブランチで最新のビルドからの成果物

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

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

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

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

重要

トリガーは、Azure DevOps が Jenkins サーバーとの通信経路を持つ場合にのみ、ホストされる Jenkins でサポートされます。

downloadBuild タスク

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

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

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

省略可能な patterns プロパティは、ダウンロードするミニマッチパスまたは minimatch パスの一覧を定義します。空白の場合、成果物全体がダウンロードされます。たとえば、次のスニペットでは、 *.zip ファイルのみがダウンロードされます。

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

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

リポジトリリソースの定義

repository キーワードを使うと、外部リポジトリを指定できます。パイプラインに別のリポジトリにテンプレートがある場合やサービス接続を必要とするリポジトリで multi-repo checkout を使用する場合は、このリソースを使用できます。これらのリポジトリについてシステムに知らせる必要があります。

次に例を示します。

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 サービス接続が必要です。

Type	名前の値	例
`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

次の例では、 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 ]

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

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

コンテナーリソース定義

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 Contributor または Owner アクセス許可が必要です。詳細については、「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

Workload ID フェデレーションを使用するサービス接続は、azureSubscriptionではサポートされていません。

コンテナーリソース変数

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

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

次の例には、arm-connectionという名前の Azure Resource Manager サービス接続があります。詳しくは、 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)

パッケージリソース定義

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

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

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

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

次の例には、contosoという名前の GitHub npm パッケージにpat-contosoという名前のGitHub サービス接続があります。詳しくは、 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 サービス接続を示すスクリーンショット。

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

{
    "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 の実行が完了するのを待つ必要も、関連のないステージ障害が原因で再実行する必要はありません。

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

リポジトリリソースバージョンピッカーを示すスクリーンショット。

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

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

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

リソース管理エクスペリエンスを使用して、リソース アクセスするためのすべてのパイプライン を承認します。たとえば、変数グループとセキュリティで保護されたファイルは Pipelines の Library ページで管理され、エージェントプールとサービス接続は Project 設定で管理されます。この承認は、テストリソースなどのリソースへのアクセスを制限する必要がない場合に便利です。
パイプラインを作成すると、YAML ファイルで参照されているすべてのリソースが、それらのリソースの User ロールを持っている場合、パイプラインで使用する権限が自動的に付与されます。
リソースを YAML ファイルに追加し、ビルドが Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.などのエラーで失敗した場合は、失敗したビルドでリソースを承認するオプションが表示されます。

リソースの User ロールのメンバーである場合は、このオプションを選択し、失敗したビルドでリソースを承認できます。リソースが承認されたら、新しいビルドを開始できます。
プロジェクトのエージェントプールのセキュリティロールが正しいことを確認します。

リソースの承認チェック

承認チェックとテンプレートを使用して、リソースの実行時を手動で制御できます。要求されたテンプレート承認チェックでは、リソースまたは環境を使用するすべてのパイプラインが特定の YAML テンプレートから拡張されることを要求できます。

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

追跡可能性

Azure Pipelines は、パイプラインまたはデプロイジョブレベルで使用されるすべてのリソースに対して完全な追跡可能性を提供します。

パイプラインの追跡可能性

Azure Pipelines には、パイプラインの実行ごとに次の情報が表示されます。

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

環境の追跡可能性

パイプラインが環境にデプロイするたびに、使われているリソースの一覧を確認できます。このビューには、デプロイジョブの一部として使用されるリソースと、関連するコミットと作業項目が含まれます。

環境内のコミットを示すスクリーンショット。

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

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

CI パイプラインの CD パイプライン情報を示すスクリーンショット。

リソーストリガーの問題

リソーストリガーは、次の理由で実行に失敗する可能性があります。

指定されたサービス接続のソースが無効であるか、トリガーに構文エラーがあるか、トリガーが構成されていません。
トリガー条件が一致しません。

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

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

トリガーの問題のサポート可能性を示すスクリーンショット。

よく寄せられる質問

パイプラインリソース、ダウンロードショートカット、またはパイプライン成果物のダウンロードタスクを使用する必要がある場合

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

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

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

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

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

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

Webhook の検証とトラブルシューティングを行うにはどうすればよいですか?

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

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

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

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

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

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

次の方法で共有

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

リソーススキーマ

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

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

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

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

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

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

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

リソース定義をビルドします

downloadBuild タスク

リポジトリリソースの定義

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

リポジトリリソース変数

リポジトリのチェックアウトキーワード

コンテナーリソース定義

Azure Container Registry リソースの種類

コンテナーリソース変数

パッケージリソース定義

Webhook リソース定義

Webhook トリガー

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

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

リソースの承認チェック

追跡可能性

パイプラインの追跡可能性

環境の追跡可能性

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

リソーストリガーの問題

よく寄せられる質問

パイプラインリソース、ダウンロードショートカット、またはパイプライン成果物のダウンロードタスクを使用する必要がある場合

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

Webhook の検証とトラブルシューティングを行うにはどうすればよいですか?

フィードバック

フィードバック

その他のリソース

次の方法で共有

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

リソース スキーマ

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

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

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

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

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

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

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

リソース定義をビルドします

downloadBuild タスク

リポジトリ リソースの定義

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

リポジトリ リソース変数

リポジトリのチェックアウト キーワード

コンテナー リソース定義

Azure Container Registry リソースの種類

コンテナー リソース変数

パッケージ リソース定義

Webhook リソース定義

Webhook トリガー

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

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

リソースの承認チェック

追跡可能性

パイプラインの追跡可能性

環境の追跡可能性

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

リソース トリガーの問題

よく寄せられる質問

パイプライン リソース、ダウンロード ショートカット、またはパイプライン成果物のダウンロード タスクを使用する必要がある場合

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

Webhook の検証とトラブルシューティングを行うにはどうすればよいですか?

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

リソーススキーマ

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

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

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

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

リポジトリリソースの定義

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

リポジトリリソース変数

リポジトリのチェックアウトキーワード

コンテナーリソース定義

コンテナーリソース変数

パッケージリソース定義

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

リソーストリガーの問題

パイプラインリソース、ダウンロードショートカット、またはパイプライン成果物のダウンロードタスクを使用する必要がある場合