YAML スキーマ リファレンス

Azure Pipelines

この記事は、Azure Pipelines yaml パイプラインの詳細なリファレンスガイドです。 サポートされているすべての YAML 機能のカタログと使用可能なオプションが含まれています。

YAML パイプラインを開始する最良の方法は、 クイックスタートガイドを読むことです。 その後、ニーズに合わせて YAML パイプラインを構成する方法については、「 ビルド変数ジョブ」などの概念的なトピックを参照してください。

ニーズに合わせて YAML パイプラインを構成する方法については、「 ビルド変数ジョブ」などの概念的なトピックを参照してください。

パイプラインの構造

パイプラインは、CI/CD のプロセスを記述する 1 つ以上のステージです。 ステージは、パイプラインの主要な区分です。 "このアプリをビルドする"、"これらのテストを実行する"、および "実稼働前環境へのデプロイ" のステージは、良い例です。

ステージは、1つまたは複数のジョブで、同じコンピューターに割り当てることができる作業単位です。 ステージとジョブの両方を依存関係グラフに配置できます。 例として、"その1つ前にこのステージを実行する" と "このジョブはそのジョブの出力に依存します。" があります。

ジョブは、順番に実行される一連のステップです。 手順には、タスク、スクリプト、または外部テンプレートへの参照を使用できます。

この階層は、次のような YAML ファイルの構造に反映されます。

  • パイプライン
    • ステージ A
      • ジョブ1
        • 手順1.1
        • 手順1.2
        • ...
      • ジョブ2
        • 手順 2.1
        • 手順 2.2
        • ...
    • ステージ B
      • ...

単純なパイプラインでは、これらのレベルのすべてを必要としません。 たとえば、1つのジョブのビルドでは、ステップのみが存在するので、ステージとジョブのコンテナーを省略できます。 また、この記事に示されている多くのオプションは必須ではなく、適切な既定値があるため、YAML 定義にはすべてが含まれる可能性はほとんどありません。

パイプラインは、CI/CD プロセスを説明する1つまたは複数のジョブです。 ジョブとは、同じマシンに割り当てられる作業単位です。 "このジョブはそのジョブの出力に依存します" のような依存関係グラフにジョブを配置できます。

ジョブは、順番に実行される一連のステップです。 手順には、タスク、スクリプト、または外部テンプレートへの参照を使用できます。

この階層は、次のような YAML ファイルの構造に反映されます。

  • パイプライン
    • ジョブ1
      • 手順1.1
      • 手順1.2
      • ...
    • ジョブ2
      • 手順 2.1
      • 手順 2.2
      • ...

単一ジョブパイプラインの場合は、手順が1つしかないので、jobs コンテナーを省略できます。 また、この記事に示されている多くのオプションは必須ではなく、適切な既定値があるため、YAML 定義にはすべてが含まれる可能性はほとんどありません。

規約

この記事で使用されている構文表記規則は次のとおりです。

  • の左側に : は、パイプライン定義で使用されるリテラルキーワードがあります。
  • : の右側は、データ型です。 データ型は、string などのプリミティブ型の場合と、この記事の別の場所で定義されているリッチ構造への参照の場合があります。
  • 表記 [ datatype ] は、言及したデータ型の配列を示します。 たとえば、 [ string ] は文字列の配列です。
  • 表記 { datatype : datatype } は、あるデータ型から別のデータ型へのマッピングです。 たとえば、 { string: string } は文字列から文字列へのマッピングです。
  • シンボルは、 | キーワードに使用できるデータ型が複数あることを示します。 たとえば、は、 job | templateReference ジョブ定義またはテンプレート参照が許可されていることを意味します。

YAML の基本

このドキュメントでは、Azure Pipelines yaml ファイルのスキーマについて説明します。 YAML の基本については、 Y 分の YAML の学習に関するページを参照してください。 Azure Pipelines は、yaml のすべての機能をサポートしていません。 サポートされていない機能には、アンカー、複雑なキー、セットなどがあります。 また、標準の yaml とは異なり、Azure Pipelines は、、、 stage job task またはマッピングの最初のキーのようなタスクのショートカットの表示に依存し script ます。

パイプライン

name: string  # build numbering format
resources:
  pipelines: [ pipelineResource ]
  containers: [ containerResource ]
  repositories: [ repositoryResource ]
variables: # several syntaxes, see specific section
trigger: trigger
pr: pr
stages: [ stage | templateReference ]

1つの ステージがある場合は、キーワードを省略 stages し、 jobs キーワードを直接指定することができます。

# ... other pipeline-level keywords
jobs: [ job | templateReference ]

1つのステージと1つのジョブがある場合は、 stages キーワードと jobs キーワードを省略し、 steps キーワードを直接指定できます。

# ... other pipeline-level keywords
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
name: string  # build numbering format
resources:
  containers: [ containerResource ]
  repositories: [ repositoryResource ]
variables: # several syntaxes, see specific section
trigger: trigger
pr: pr
jobs: [ job | templateReference ]

1つのジョブがある場合は、キーワードを省略 jobs し、 steps キーワードを直接指定することができます。

# ... other pipeline-level keywords
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

各項目の詳細情報

段階

ステージは、関連するジョブのコレクションです。 既定では、ステージは順番に実行されます。 各ステージは、プロパティで特に指定されていない限り、前のステージが完了した後にのみ開始され dependsOn ます。

承認チェックを使用して、ステージをいつ実行するかを手動で制御します。 これらのチェックは、通常、運用環境への配置を制御するために使用されます。

リソース所有者 が使用できるメカニズムを確認します。 パイプライン内のステージがリソースを使用するタイミングを制御します。 環境のようなリソースの所有者は、リソースを使用するステージを開始する前に必要なチェックを定義できます。

現時点では、手動による承認チェックは 環境でサポートされています。 詳細については、「 承認」を参照してください。

stages:
- stage: string  # name of the stage (A-Z, a-z, 0-9, and underscore)
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  variables: # several syntaxes, see specific section
  jobs: [ job | templateReference]

ステージ条件、および変数の詳細については、こちらを参照してください。

ジョブ

ジョブは、エージェントまたはサーバーで実行されるステップのコレクションです。 ジョブは 条件 に応じて実行でき、 以前のジョブに依存する場合があります。

jobs:
- job: string  # name of the job (A-Z, a-z, 0-9, and underscore)
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy; see the following "Parallel" topic
    matrix: # matrix strategy; see the following "Matrix" topic
    maxParallel: number # maximum number of matrix jobs to run simultaneously
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # see the following "Pool" schema
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside of
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

の詳細について uses は、「制限ジョブ承認スコープを参照される Azure DevOps リポジトリに制限する」を参照してください。 クリーンオプションを含むワークスペースの詳細については、「ジョブ」の「ワークスペース」を参照してください。

jobs:
- job: string  # name of the job (A-Z, a-z, 0-9, and underscore)
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy; see the following "Parallel" topic
    matrix: # matrix strategy; see the following "Matrix" topic
    maxParallel: number # maximum number of matrix jobs to run simultaneously
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # see the following "Pool" schema
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside of
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

クリーンオプションを含むワークスペースの詳細については、「ジョブ」の「ワークスペース」を参照してください。

詳細については、「 変数ステッププール、および サーバージョブ」を参照してください。

注意

1つのステージと1つのジョブのみがある場合は、実行する手順を説明するための短い方法として、 単一のジョブの構文 を使用できます。

コンテナー参照

コンテナーはジョブによってサポートされています。

container: string # Docker Hub image reference or resource alias
container:
  image: string  # container image name
  options: string  # arguments to pass to container at startup
  endpoint: string  # endpoint for a private container registry
  env: { string: string }  # list of environment variables to add
  # you can also use any of the other supported container attributes

方法

matrixキーワードと parallel キーワードは、ジョブを複製するための相互排他的な戦略を指定します。

Matrix

マトリックスを使用すると、ジョブのコピーが生成され、それぞれの入力が異なります。 これらのコピーは、さまざまな構成またはプラットフォームのバージョンに対してテストする場合に便利です。

strategy:
  matrix: { string1: { string2: string3 } }
  maxParallel: number

マトリックスで string1 が出現するたびに、ジョブのコピーが生成されます。 String1 という名前はコピーの名前で、ジョブの名前に追加されます。 String2 が出現するたびに、値 string3 を持つ string2 という変数をジョブで使用できます。

注意

マトリックス構成名には、基本的なラテンアルファベット文字 (A ~ Z と a ~ z)、数字 (0-9)、およびアンダースコア () のみを含める必要があり _ ます。 先頭は文字でなければなりません。 また、長さは100文字以下でなければなりません。

省略可能 maxParallel なキーワードでは、同時に実行するマトリックス脚の最大数を指定します。

が指定されていない maxParallel か、または0に設定されている場合、制限は適用されません。

が指定されていない場合 maxParallel 、制限は適用されません。

注意

この構文では自動ジョブスケーリングはサポートされてい matrix ませんが、キーワードを使用して同様の機能を実装でき each ます。 例については、「 」を参照してください。

並列

この方法では、実行するジョブの重複数を指定します。 これは、大規模なテストマトリックスをスライスする場合に便利です。 Visual Studio テストタスクは、スケジュールされたジョブの数に対してテスト負荷を分割する方法を理解します。

strategy:
  parallel: number

配置ジョブ

配置ジョブは、特別な種類のジョブです。 これは、環境に対して順番に実行する手順のコレクションです。 YAML パイプラインでは、デプロイの手順をデプロイジョブに含めることをお勧めします。

jobs:
- deployment: string   # name of the deployment job, A-Z, a-z, 0-9, and underscore. The word "deploy" is a keyword and is unsupported as the deployment name.
  displayName: string  # friendly name to display in the UI
  pool:                # see pool schema
    name: string       # Use only global level variables for defining a pool name. Stage/job level variables are not supported to define pool name.
    demands: string | [ string ]
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  dependsOn: string
  condition: string
  continueOnError: boolean                # 'true' if future jobs should run even if this job fails; defaults to 'false'
  container: containerReference # container to run this job inside
  services: { string: string | container } # container resources to run as a service container
  timeoutInMinutes: nonEmptyString        # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: nonEmptyString  # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  environment: string  # target environment name and optionally a resource name to record the deployment history; format: <environment-name>.<resource-name>
  strategy:
    runOnce:    #rolling, canary are the other strategies that are supported
      deploy:
        steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

手順

ステップは、ジョブを構成する一連の操作です。 各ステップは、エージェント上で独自のプロセスで実行され、ローカルハードドライブ上のパイプラインワークスペースにアクセスできます。 この動作は、環境変数がステップ間で保持されるのではなく、ファイルシステムの変更があることを意味します。

steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

手順の詳細については、次のスキーマ参照を参照してください。

この記事に記載されているかどうかにかかわらず、すべての手順は次のプロパティをサポートしています。

  • displayName
  • name
  • condition
  • continueOnError
  • 有効
  • エンベロープ
  • timeoutInMinutes

変数

ハードコーディングされた値を直接追加したり、 変数グループを参照したり、変数テンプレートを使用して挿入したりすることができます。

パイプライン、ステージ、またはジョブレベルで変数を指定します。

ハードコーディングされた単純な変数のセットについては、次のマッピング構文を使用します。

variables: { string: string }

変数グループを含めるには、次のシーケンス構文に切り替えます。

variables:
- name: string  # name of a variable
  value: string # value of the variable
- group: string # name of a variable group

ペアとを繰り返すことができ name / value group ます。

変数は、 セキュリティを強化するために読み取り専用として設定することもできます。

variables:
- name: myReadOnlyVar
  value: myValue
  readonly: true

テンプレートから変数を含めることもできます。

テンプレート リファレンス

注意

すべての形式の テンプレート式の完全な構文を確認してください ${{ }}

パイプラインの再利用可能なセクションを別のファイルにエクスポートできます。 これらの個別のファイルはテンプレートと呼ばれています。

Azure Pipelines は、次の4種類のテンプレートをサポートしています。

また、テンプレートを使用して、パイプラインで許可される内容を制御したり、パラメーターを使用する方法を定義したりすることもできます。

パイプラインの再利用可能なセクションを別のファイルにエクスポートできます。 これらの個別のファイルはテンプレートと呼ばれています。 Azure DevOps Server 2019 は、次の2種類のテンプレートをサポートしています。

テンプレート自体に他のテンプレートを含めることができます。 Azure Pipelines は、1つのパイプラインで最大50の一意のテンプレートファイルをサポートします。

ステージ テンプレート

1つのファイルで一連のステージを定義し、他のファイルで複数回使用することができます。

メインパイプラインで、次のようにします。

- template: string # name of template to include
  parameters: { string: any } # provided parameters

含まれているテンプレート:

parameters: { string: any } # expected parameters
stages: [ stage ]

ジョブ テンプレート

一連のジョブを 1 つのファイルで定義し、他のファイルで複数回使用できます。

メイン パイプラインで次の処理を行います。

- template: string # name of template to include
  parameters: { string: any } # provided parameters

含まれているテンプレートでは、次の情報を使用します。

parameters: { string: any } # expected parameters
jobs: [ job ]

ジョブ テンプレートの操作 の詳細については、テンプレートに関するページを参照してください。

ステップ テンプレート

1 つのファイルで一連のステップを定義し、別のファイルで複数回使用できます。

メイン パイプラインで次の処理を行います。

steps:
- template: string  # reference to template
  parameters: { string: any } # provided parameters

含まれているテンプレートでは、次の情報を使用します。

parameters: { string: any } # expected parameters
steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

テンプレート の操作の 詳細については、「テンプレート」を参照してください。

変数テンプレート

1 つのファイルで変数のセットを定義し、他のファイルで複数回使用できます。

メイン パイプラインで次の処理を行います。

- template: string            # name of template file to include
  parameters: { string: any } # provided parameters

含まれているテンプレートでは、次の情報を使用します。

parameters: { string: any }   # expected parameters
variables: [ variable ]

注意

キーワード variables は、シーケンスとマッピングの 2 つの構文形式を使用します。 マッピング構文では、すべてのキーは変数名であり、その値は変数値です。 変数テンプレートを使用するには、シーケンス構文を使用する必要があります。 シーケンス構文では、変数 ( )、変数グループ ( )、またはテンプレート ( ) をメンションするかどうかを name group 指定する必要があります template 。 詳細については 、変数に関する トピックを参照してください。

パラメーター

テンプレートとパイプラインでパラメーターを使用できます。

型フィールドと名前フィールドは、パラメーターを定義するときに必要です。 すべてのパラメーター データ 型を参照してください

parameters:
- name: string          # name of the parameter; required
  type: enum            # see the enum data types in the following section
  default: any          # default value; if no default, then the parameter MUST be given by the user at runtime
  values: [ string ]    # allowed list of values (for some data types)

種類

type は、次の表の enum メンバーの 1 つである必要があります。

データ型 Notes
string string
number は に制限される場合 values: があります。それ以外の場合は、任意の数値に似た文字列が受け入れ可能です。
boolean true または false
object 任意の YAML 構造体
step 1 つのステップ
stepList ステップの シーケンス
job 1 つのジョブ
jobList ジョブの シーケンス
deployment 1 つのデプロイ ジョブ
deploymentList デプロイ ジョブの シーケンス
stage 1 つのステージ
stageList ステージ のシーケンス

step、stepList、job、jobList、deployment、deploymentList、stage、stageList のデータ型はすべて、標準の YAML スキーマ形式を使用します。 この例には、文字列、数値、ブール値、オブジェクト、ステップ、stepList が含まれます。

parameters:
- name: myString
  type: string
  default: a string
- name: myMultiString
  type: string
  default: default
  values:
  - default
  - ubuntu
- name: myNumber
  type: number
  default: 2
  values:
  - 1
  - 2
  - 4
  - 8
  - 16
- name: myBoolean
  type: boolean
  default: true
- name: myObject
  type: object
  default:
    foo: FOO
    bar: BAR
    things:
    - one
    - two
    - three
    nested:
      one: apple
      two: pear
      count: 3
- name: myStep
  type: step
  default:
    script: echo my step
- name: mySteplist
  type: stepList
  default:
    - script: echo step one
    - script: echo step two

trigger: none

jobs: 
- job: stepList
  steps: ${{ parameters.mySteplist }}
- job: myStep
  steps:
    - ${{ parameters.myStep }}

リソース

リソースは、パイプラインの一部として使用される外部サービスです。 リソースの例として、次を生成するもう 1 つの CI/CD パイプラインがあります。

  • Artifactsや Jenkins Azure Pipelinesなど)。
  • コード リポジトリ (GitHub、Azure Repos Git など)。
  • コンテナー イメージ レジストリ (Azure Container Registry Docker ハブなど)。

YAML のリソースは、パイプライン、コンテナー、リポジトリ、および型のソースを表します。 リソースの詳細については、こちらを 参照してください

一般的なスキーマ

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]

パイプライン リソース

成果物を生成する Azure パイプラインがある場合は、 キーワードを使用してパイプライン リソースを定義することで、パイプラインで成果物 pipeline を使用できます。 パイプライン補完トリガー を有効にできます

resources:
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers are not enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional; 2020.1 and greater
      stages: [ string ] # list of stages to evaluate for trigger event, optional; 2020.1 and greater

重要

リソース トリガーを定義するときに、そのパイプライン リソースが現在のパイプラインと同じリポジトリからの場合、トリガーは同じブランチに従い、イベントが発生するコミットに従います。 ただし、パイプライン リソースが別のレポから取得された場合、現在のパイプラインは、手動ビルドとスケジュールされたビルド設定の既定のブランチで トリガー されます。 詳細については、「パイプライン完了トリガー のブランチに関する考慮事項」を参照してください

定義済みの変数としてのパイプライン リソース メタデータ

各実行で、パイプライン リソースのメタデータは、次の定義済み変数としてすべてのジョブで使用できます。

resources.pipeline.<Alias>.projectName
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

タスクを使用して、パイプライン リソースから成果物を使用 download できます。 download キーワード を参照 してください。

コンテナー リソース

コンテナー ジョブ を使用すると、コンテナー内でツールと依存関係を分離できます。 エージェントは、指定したコンテナーのインスタンスを起動し、その中でステップを実行します。 キーワード container を使用すると、コンテナー イメージを指定できます。

サービス コンテナーは 、データベースなど、さまざまな依存関係を提供するためにジョブと共に実行されます。

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory
resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container

リポジトリ リソース

パイプラインに別の リポジトリにテンプレートがある場合は、そのリポジトリについてシステムに知らせる必要があります。 キーワード repository を使用すると、外部リポジトリを指定できます。

パイプラインに別のリポジトリにテンプレートがある場合、またはサービス接続を必要とするリポジトリでマルチリポジトリ チェックアウトを使用する場合は、そのリポジトリについてシステムに知らせる必要があります。 キーワード repository を使用すると、外部リポジトリを指定できます。

resources:
  repositories:
  - repository: string  # identifier (A-Z, a-z, 0-9, and underscore)
    type: enum  # see the following "Type" topic
    name: string  # repository name (format depends on `type`)
    ref: string  # ref name to use; defaults to 'refs/heads/main'
    endpoint: string  # name of the service connection to use (for types that aren't Azure Repos)
    trigger:  # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos)
      branches:
        include: [ string ] # branch names which will trigger a build
        exclude: [ string ] # branch names which will not
      tags:
        include: [ string ] # tag names which will trigger a build
        exclude: [ string ] # tag names which will not
      paths:
        include: [ string ] # file paths which must match to trigger a build
        exclude: [ string ] # file paths which will not trigger a build

Pipelines、、および のリポジトリの種類に対して、次の gitgithub がサポートされています bitbucket 。 型 git は、Git リポジトリAzure Repos参照します。

  • を指定した type: git 場合、値 name は同じプロジェクト内の別のリポジトリを参照します。 たとえば name: otherRepo です。 同じ組織内の別のプロジェクトのレポポを参照するには、名前の前にそのプロジェクトの名前を付きます。 たとえば name: OtherProject/otherRepo です。

  • を指定した type: github 場合、この値は、ユーザーまたは組織GitHubの完全な name 名前です。 たとえば name: Microsoft/vscode です。 GitHubリポジトリには、承認GitHubサービス接続が必要です。

  • を指定した場合、値は Bitbucket Cloud レポポの完全な名前であり、ユーザー type: bitbucket name または組織が含まれます。 たとえば name: MyBitbucket/vscode です。 Bitbucket Cloud リポジトリでは、承認のために Bitbucket Cloud サービス接続が 必要です。

パッケージ リソース

YAML パイプラインNuGetリソースとしてGitHubおよび npm パッケージを使用できます。 パッケージ リソースを指定する場合は、パッケージを または に設定 NuGet します npm

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # Github service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

トリガー

注意

トリガーブロックには、変数またはテンプレート式を含めることはできません。

プッシュ トリガー

プッシュトリガーでは、継続的インテグレーションビルドを実行する分岐を指定します。 プッシュトリガーが指定されていない場合、分岐にプッシュすると、ビルドがトリガーされます。 トリガーとその指定方法の詳細については、こちらを参照してください。

キーワードには3つの異なる構文オプションがあり trigger ます。含める分岐のリスト、CI トリガーを無効にする方法、完全な制御の完全な構文です。

リスト構文:

trigger: [ string ] # list of branch names

無効化構文:

trigger: none # will disable CI builds entirely

完全な構文:

trigger:
  batch: boolean # batch changes if true; start a new build for every push if false (default)
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  tags:
    include: [ string ] # tag names which will trigger a build
    exclude: [ string ] # tag names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build

exclude、、またはの句を指定せずに句を指定すると、句 include でを branches tags paths 指定するのと同じ結果になり * include ます。

trigger:
  batch: boolean # batch changes if true; start a new build for every push if false (default)
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build

重要

トリガーを指定すると、包含するように明示的に構成したブランチだけがパイプラインをトリガーします。 インクルードは最初に処理された後、除外はそのリストから削除されます。 除外を指定しても、包含は指定しなかった場合は、何もトリガーしません。

PR トリガー

プル要求のトリガーは、プル要求のビルドを実行する分岐を指定します。 プル要求のトリガーを指定しない場合、すべての分岐にプル要求を実行すると、ビルドがトリガーされます。 プル要求トリガーとその指定方法の詳細については、こちらを参照してください。

重要

yaml PR トリガーは、GitHub と Bitbucket Cloud でのみサポートされています。 Azure Repos Git を使用する場合は、ビルド検証用の分岐ポリシーを構成して、検証のためにビルドパイプラインをトリガーすることができます。

重要

YAML PR トリガーは、GitHub でのみサポートされています。 Azure Repos Git を使用する場合は、ビルド検証用の分岐ポリシーを構成して、検証のためにビルドパイプラインをトリガーすることができます。

キーワードには3つの異なる構文オプションがあり pr ます。含める分岐のリスト、PR トリガーを無効にする方法、および完全な制御の完全な構文です。

リスト構文:

pr: [ string ] # list of branch names

無効化構文:

pr: none # will disable PR builds entirely; will not disable CI triggers

完全な構文:

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # For GitHub only, whether to build draft PRs, defaults to true

excludeまたはの句を指定せずに句を指定すると include 、句でを branches paths 指定するのと同じ結果になり * include ます。

重要

プル要求のトリガーを指定すると、包含するように明示的に構成したブランチだけがパイプラインをトリガーします。 インクルードは最初に処理された後、除外はそのリストから削除されます。 除外を指定しても、包含は指定しなかった場合は、何もトリガーしません。

スケジュールされたトリガー

yaml のスケジュールされたトリガーは、このバージョンの Azure DevOps Server または Visual Studio Team Foundation Server では使用できません。 スケジュールされた トリガーは、クラシックエディターで使用できます。

スケジュールされたトリガーでは、分岐を作成するスケジュールを指定します。 スケジュールされたトリガーを指定しない場合、スケジュールされたビルドは実行されません。 スケジュールされた トリガー とその指定方法の詳細については、こちらを参照してください。

schedules:
- cron: string # cron syntax defining a schedule in UTC time
  displayName: string # friendly name given to a specific schedule
  branches:
    include: [ string ] # which branches the schedule applies to
    exclude: [ string ] # which branches to exclude from the schedule
  always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.

注意

に句を指定せずに句を指定すると exclude include 、句でを branches 指定するのと同じ結果になり * include ます。

パイプライントリガー

パイプラインの完了トリガーは、 パイプラインリソースを使用して構成されます。 詳細については、「 パイプライン完了トリガー」を参照してください。

プール

キーワードは、 pool パイプラインのジョブに使用する プール を指定します。 また、仕様には pool 、を実行するためのジョブの戦略に関する情報も保持されます。

Azure DevOps Server 2019 では、yaml のジョブレベルでプールを指定し、パイプラインの設定 UI でパイプラインレベルでプールを指定できます。 Azure DevOps Server 2019.1 では、1つの暗黙的なジョブがある場合は、yaml のパイプラインレベルでプールを指定することもできます。

パイプライン、ステージ、またはジョブレベルでプールを指定できます。

階層の最下位レベルで指定されたプールは、ジョブの実行に使用されます。

完全な構文は次のとおりです。

pool:
  name: string  # name of the pool to run this job in
  demands: string | [ string ]  # see the following "Demands" topic
  vmImage: string # name of the VM image you want to use; valid only in the Microsoft-hosted pool

Microsoft がホストするプールを使用する場合は、 使用可能な仮想マシンイメージを選択します。

プライベートプールを使用し、要求を指定する必要がない場合は、構文を次のように短縮できます。

pool: string # name of the private pool to run this job in

条件タイムアウトの詳細についてはこちらをご覧ください。

確認要求

キーワードは、 demands プライベートプールでサポートされています。 機能または特定の文字列が存在するかどうかを確認できます。

pool:
  demands: [ string ]

要求の詳細についてはこちらをご覧ください。

環境

キーワードは、 environment パイプラインの配置ジョブの対象となる 環境 またはそのリソースを指定します。 また、環境には、ジョブ内で定義されているステップを実行するための配置方法に関する情報も保持されます。

完全な構文は次のとおりです。

environment:                # create environment and/or record deployments
  name: string              # name of the environment to run this job on.
  resourceName: string      # name of the resource in the environment to record the deployments against
  resourceId: number        # resource identifier
  resourceType: string      # type of the resource you want to target. Supported types - virtualMachine, Kubernetes
  tags: string | [ string ] # tag names to filter the resources in the environment
strategy:                 # deployment strategy
  runOnce:                # default strategy
    deploy:
      steps:
      - script: echo Hello world

環境またはリソースの1つを指定し、他のプロパティを指定する必要がない場合は、構文を次のように短縮できます。

environment: environmentName.resourceName
strategy:                 # deployment strategy
  runOnce:              # default strategy
    deploy:
      steps:
      - script: echo Hello world

サーバー

この server 値は、 サーバージョブを指定します。 サーバージョブで実行できるのは、 Azure function app の呼び出し などのサーバータスクだけです。

を使用すると server 、ジョブはエージェントジョブではなく、サーバージョブとして実行されます。

pool: server

Script

scriptキーワードは、コマンドラインタスクのショートカットです。 このタスクでは、他のプラットフォーム上で Windows と Bash の cmd.exe を使用してスクリプトを実行します。

steps:
- script: string  # contents of the script to run
  displayName: string  # friendly name displayed in the UI
  name: string  # identifier for this step (A-Z, a-z, 0-9, and underscore)
  workingDirectory: string  # initial working directory for the step
  failOnStderr: boolean  # if the script writes to stderr, should that be treated as the step failing?
  condition: string
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean  # whether to run this step; defaults to 'true'
  target:
    container: string # where this step will run; values are the container name or the word 'host'
    commands: enum  # whether to process all logging commands from this step; values are `any` (default) or `restricted`
  timeoutInMinutes: number
  env: { string: string }  # list of environment variables to add

コマンドモードを指定しない場合は、 target 次のように構造を短くすることができます。

- script:
  target: string  # container name or the word 'host'

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。

Bash

bashキーワードは、シェルスクリプトタスクのショートカットです。 このタスクは、Windows、macOS、Linux の Bash でスクリプトを実行します。

steps:
- bash: string  # contents of the script to run
  displayName: string  # friendly name displayed in the UI
  name: string  # identifier for this step (A-Z, a-z, 0-9, and underscore)
  workingDirectory: string  # initial working directory for the step
  failOnStderr: boolean  # if the script writes to stderr, should that be treated as the step failing?
  condition: string
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean  # whether to run this step; defaults to 'true'
  target:
    container: string # where this step will run; values are the container name or the word 'host'
    commands: enum  # whether to process all logging commands from this step; values are `any` (default) or `restricted`
  timeoutInMinutes: number
  env: { string: string }  # list of environment variables to add

コマンドモードを指定しない場合は、 target 次のように構造を短くすることができます。

- bash:
  target: string  # container name or the word 'host'

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。

pwsh

キーワードは、 pwsh そのタスクの pwsh 値が true に設定されている場合の PowerShell タスクのショートカットです。 このタスクは、Windows、macOS、Linux の PowerShell Core でスクリプトを実行します。

steps:
- pwsh: string  # contents of the script to run
  displayName: string  # friendly name displayed in the UI
  name: string  # identifier for this step (A-Z, a-z, 0-9, and underscore)
  errorActionPreference: enum  # see the following "Error action preference" topic
  ignoreLASTEXITCODE: boolean  # see the following "Ignore last exit code" topic
  failOnStderr: boolean  # if the script writes to stderr, should that be treated as the step failing?
  workingDirectory: string  # initial working directory for the step
  condition: string
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean  # whether to run this step; defaults to 'true'
  timeoutInMinutes: number
  env: { string: string }  # list of environment variables to add

注意

各 PowerShell セッションは、ジョブが実行されている間だけ継続されます。 ブートストラップの内容に依存するタスクは、ブートストラップと同じジョブ内に存在する必要があります。

条件タイムアウトの詳細についてはこちらをご覧ください。

PowerShell

powershellキーワードは、 PowerShell タスクのショートカットです。 このタスクは Windows PowerShell でスクリプトを実行します。

steps:
- powershell: string  # contents of the script to run
  displayName: string  # friendly name displayed in the UI
  name: string  # identifier for this step (A-Z, a-z, 0-9, and underscore)
  errorActionPreference: enum  # see the following "Error action preference" topic
  ignoreLASTEXITCODE: boolean  # see the following "Ignore last exit code" topic
  failOnStderr: boolean  # if the script writes to stderr, should that be treated as the step failing?
  workingDirectory: string  # initial working directory for the step
  condition: string
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean  # whether to run this step; defaults to 'true'
  timeoutInMinutes: number
  env: { string: string }  # list of environment variables to add

注意

各 PowerShell セッションは、ジョブが実行されている間だけ継続されます。 ブートストラップの内容に依存するタスクは、ブートストラップと同じジョブ内に存在する必要があります。

条件タイムアウトの詳細についてはこちらをご覧ください。

エラーアクションの設定

特に指定しない限り、[エラーアクション] 設定は既定値に設定され、 stop$ErrorActionPreference = 'stop' はスクリプトの先頭に付加されます。

エラーアクションの設定が [停止] に設定されている場合、エラーが発生すると、PowerShell によってタスクが終了し、0以外の終了コードが返されます。 タスクも失敗としてマークされています。

errorActionPreference: stop | continue | silentlyContinue

最後の終了コードを無視する

スクリプトから返された最後の終了コードは、既定ではオンになっています。 0以外のコードはステップが失敗したことを示します。この場合、システムは次のようにスクリプトを追加します。

if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }

この動作が不要な場合は、を指定し ignoreLASTEXITCODE: true ます。

ignoreLASTEXITCODE: boolean

条件タイムアウトの詳細についてはこちらをご覧ください。

公開

publishキーワードは、パイプラインアーティファクトの発行タスクのショートカットです。 このタスクは、他のジョブやパイプラインが使用できるパイプラインアーティファクトとしてファイルまたはフォルダーを発行 (アップロード) します。

steps:
- publish: string # path to a file or folder
  artifact: string # artifact name
  displayName: string  # friendly name to display in the UI

成果物の公開についての詳細情報。

ダウンロード

downloadキーワードは、パイプラインアーティファクトのダウンロードタスクのショートカットです。 このタスクは、現在の実行に関連付けられている成果物、またはパイプラインリソースとして関連付けられている別の Azure パイプラインからの成果物をダウンロードします。

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional
  displayName: string  # friendly name to display in the UI

成果物のダウンロード場所

現在のパイプラインからの Artifacts はにダウンロードされ $(**Pipeline.Workspace**)/<artifact name> ます。

関連付けられているパイプラインリソースの Artifacts がにダウンロードされ $(**Pipeline.Workspace**)/\<pipeline resource identifier\>/<artifact name> ます。

デプロイジョブでの自動ダウンロード

現在のパイプラインおよび関連するパイプラインリソースから使用可能なすべてのアイテムは、デプロイジョブに自動的にダウンロードされ、デプロイに使用できるようになります。 ダウンロードが行われないようにするには、を指定し download: none ます。

アーティファクトのダウンロードに関する詳細情報。

チェックアウト

配置以外のジョブでは、ソースコードが自動的にチェックアウトされます。 checkoutこの動作を構成または非表示にするには、キーワードを使用します。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # if true, execute `execute git clean -ffdx && git reset --hard HEAD` before fetching
  fetchDepth: number  # the depth of commits to ask Git to fetch (applies to submodules too if they're enabled); defaults to no limit
  lfs: boolean  # whether to download Git-LFS files; defaults to false
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
  persistCredentials: boolean  # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false
steps:
- checkout: self | none | repository name # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # if true, run `execute git clean -ffdx && git reset --hard HEAD` before fetching
  fetchDepth: number  # the depth of commits to ask Git to fetch; defaults to no limit
  lfs: boolean  # whether to download Git-LFS files; defaults to false
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
  persistCredentials: boolean  # if 'true', leave the OAuth token in the Git config after the initial fetch; defaults to false

注意

を使用して使用できるクリーニングオプションに加えて checkout 、ワークスペースでクリーニングを構成することもできます。 クリーンオプションを含むワークスペースの詳細については、「ジョブ」の「ワークスペース」を参照してください。

ソースの同期をまったく行わないようにするには:

steps:
- checkout: none

注意

ローカルサービスアカウントでエージェントを実行していて、git 操作を使用して現在のリポジトリを変更する場合、または git サブモジュールを読み込む場合は、Project コレクションビルドサービスアカウントユーザーに適切なアクセス許可を付与します。

- checkout: self
  submodules: true
  persistCredentials: true

パイプラインで複数のリポジトリをチェックアウトするには、複数の手順を使用し checkout ます。

- checkout: self
- checkout: git://MyProject/MyRepo
- checkout: MyGitHubRepo # Repo declared in a repository resource

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

タスク

タスク は、パイプラインの構成要素です。 選択できる タスクのカタログ があります。

steps:
- task: string  # reference to a task and version, e.g. "VSBuild@1"
  displayName: string  # friendly name displayed in the UI
  name: string  # identifier for this step (A-Z, a-z, 0-9, and underscore)
  condition: string
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean  # whether to run this step; defaults to 'true'
  target:
    container: string # where this step will run; values are the container name or the word 'host'
    commands: enum  # whether to process all logging commands from this step; values are `any` (default) or `restricted`
    settableVariables: string # what variables are allowed; defaults to all; can be `none` or a list of allowed vars
  timeoutInMinutes: number
  inputs: { string: string }  # task-specific inputs
  env: { string: string }  # list of environment variables to add

コマンドモードを指定しない場合は、 target 次のように構造を短くすることができます。

- task:
  target: string  # container name or the word 'host'

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。

構文の強調表示

構文の強調表示は、パイプラインスキーマで Visual Studio Code 拡張機能を使用して利用できます。 Visual Studio Code をダウンロードして、拡張機能をインストールし、 GitHub でプロジェクトをチェックアウトすることができます。 拡張機能には、検証用の JSON スキーマ が含まれています。

また、 Azure DevOps REST API yamlschema エンドポイントから、組織に固有のスキーマ (インストールされているカスタムタスクを含む) を取得することもできます。