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

次の例では、リソースの 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

次の例では、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 リソースからのリポジトリは、ジョブ内では自動的に同期されません。 repository リソースの一部として定義されたリポジトリを取得するには、checkout キーワードを使用します。スキーマの詳細については、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 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)

パッケージリソース定義

YAML パイプラインのリソースとして、NuGet パッケージと npm GitHub パッケージを使用できます。新しいパッケージバージョンがリリースされたときに自動パイプライントリガーを有効にするには、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 実行が完了するまで待機する必要も、無関係なステージの失敗のために 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 パイプライン実行が表示されます。

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

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

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

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

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

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

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

よく寄せられる質問

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

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

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

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

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 はパイプラインで使用できる状態になっています。

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

パイプラインページの [編集] を選択します。
[その他の操作] メニューから、[トリガー] を選択します。
[YAML] タブを選択し、[ソースの取得] を選択します。
[手動のビルドとスケジュールされたビルドの既定のブランチ] の下で、機能ブランチを更新します。
[保存して & キューに登録] を選択します。
このパイプラインが正常に実行した後、本文で 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 を検証してトラブルシューティングするにはどうすればよいですか?

関連するコンテンツ

フィードバック

その他のリソース

リソーススキーマ

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

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

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

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

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

ビルドリソース定義

リポジトリリソース定義

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

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

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

コンテナーリソース定義

コンテナーリソース変数

パッケージリソース定義

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

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

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