YAML スキーマ リファレンスYAML schema reference

Azure PipelinesAzure Pipelines

この記事は、Azure Pipelines YAML パイプラインの詳細なリファレンスガイドです。This article is a detailed reference guide to Azure Pipelines YAML pipelines. サポートされているすべての YAML 機能のカタログと使用可能なオプションが含まれています。It includes a catalog of all supported YAML capabilities and the available options.

YAML パイプラインを開始する最良の方法は、 クイックスタートガイドを読むことです。The best way to get started with YAML pipelines is to read the quickstart guide. その後、ニーズに合わせて YAML パイプラインを構成する方法については、「 ビルド変数ジョブ」などの概念的なトピックを参照してください。After that, to learn how to configure your YAML pipeline for your needs, see conceptual topics like Build variables and Jobs.

ニーズに合わせて YAML パイプラインを構成する方法については、「 ビルド変数ジョブ」などの概念的なトピックを参照してください。To learn how to configure your YAML pipeline for your needs, see conceptual topics like Build variables and Jobs.

パイプラインの構造Pipeline structure

パイプラインは、CI/CD のプロセスを記述する 1 つ以上のステージです。A pipeline is one or more stages that describe a CI/CD process. ステージは、パイプラインの主要な区分です。Stages are the major divisions in a pipeline. "このアプリをビルドする"、"これらのテストを実行する"、および "実稼働前環境へのデプロイ" のステージは、良い例です。The stages "Build this app," "Run these tests," and "Deploy to preproduction" are good examples.

ステージは、1つまたは複数のジョブで、同じコンピューターに割り当てることができる作業単位です。A stage is one or more jobs, which are units of work assignable to the same machine. ステージとジョブの両方を依存関係グラフに配置できます。You can arrange both stages and jobs into dependency graphs. 例として、"その1つ前にこのステージを実行する" と "このジョブはそのジョブの出力に依存します。" があります。Examples include "Run this stage before that one" and "This job depends on the output of that job."

ジョブは、順番に実行される一連のステップです。A job is a linear series of steps. 手順には、タスク、スクリプト、または外部テンプレートへの参照を使用できます。Steps can be tasks, scripts, or references to external templates.

この階層は、次のような YAML ファイルの構造に反映されます。This hierarchy is reflected in the structure of a YAML file like:

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

単純なパイプラインでは、これらのレベルのすべてを必要としません。Simple pipelines don't require all of these levels. たとえば、1つのジョブのビルドでは、ステップのみが存在するので、ステージとジョブのコンテナーを省略できます。For example, in a single-job build you can omit the containers for stages and jobs because there are only steps. また、この記事に示されている多くのオプションは必須ではなく、適切な既定値があるため、YAML 定義にはすべてが含まれる可能性はほとんどありません。And because many options shown in this article aren't required and have good defaults, your YAML definitions are unlikely to include all of them.

パイプラインは、CI/CD プロセスを説明する1つまたは複数のジョブです。A pipeline is one or more jobs that describe a CI/CD process. ジョブとは、同じマシンに割り当てられる作業単位です。A job is a unit of work assignable to the same machine. "このジョブはそのジョブの出力に依存します" のような依存関係グラフにジョブを配置できます。You can arrange jobs into dependency graphs like "This job depends on the output of that job."

ジョブは、順番に実行される一連のステップです。A job is a linear series of steps. 手順には、タスク、スクリプト、または外部テンプレートへの参照を使用できます。Steps can be tasks, scripts, or references to external templates.

この階層は、次のような YAML ファイルの構造に反映されます。This hierarchy is reflected in the structure of a YAML file like:

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

単一ジョブパイプラインの場合は、手順が1つしかないので、jobs コンテナーを省略できます。For single-job pipelines, you can omit the jobs container because there are only steps. また、この記事に示されている多くのオプションは必須ではなく、適切な既定値があるため、YAML 定義にはすべてが含まれる可能性はほとんどありません。And because many options shown in this article aren't required and have good defaults, your YAML definitions are unlikely to include all of them.

規約Conventions

この記事で使用されている構文表記規則は次のとおりです。Here are the syntax conventions used in this article:

  • の左側に : は、パイプライン定義で使用されるリテラルキーワードがあります。To the left of : is a literal keyword used in pipeline definitions.
  • : の右側は、データ型です。To the right of : is a data type. データ型は、string などのプリミティブ型の場合と、この記事の別の場所で定義されているリッチ構造への参照の場合があります。The data type can be a primitive type like string or a reference to a rich structure defined elsewhere in this article.
  • 表記 [ datatype ] は、言及したデータ型の配列を示します。The notation [ datatype ] indicates an array of the mentioned data type. たとえば、 [ string ] は文字列の配列です。For instance, [ string ] is an array of strings.
  • 表記 { datatype : datatype } は、あるデータ型から別のデータ型へのマッピングです。The notation { datatype : datatype } indicates a mapping of one data type to another. たとえば、 { string: string } は文字列から文字列へのマッピングです。For instance, { string: string } is a mapping of strings to strings.
  • シンボルは、 | キーワードに使用できるデータ型が複数あることを示します。The symbol | indicates there are multiple data types available for the keyword. たとえば、は、 job | templateReference ジョブ定義またはテンプレート参照が許可されていることを意味します。For instance, job | templateReference means either a job definition or a template reference is allowed.

YAML の基本YAML basics

このドキュメントでは、Azure Pipelines YAML ファイルのスキーマについて説明します。This document covers the schema of an Azure Pipelines YAML file. YAML の基本については、 Y 分の YAML の学習に関するページを参照してください。To learn the basics of YAML, see Learn YAML in Y Minutes. Azure Pipelines は、YAML のすべての機能をサポートしていません。Azure Pipelines doesn't support all YAML features. サポートされていない機能には、アンカー、複雑なキー、セットなどがあります。Unsupported features include anchors, complex keys, and sets. また、標準の yaml とは異なり、Azure Pipelines は、、、 stage job task またはマッピングの最初のキーのようなタスクのショートカットの表示に依存し script ます。Also, unlike standard YAML, Azure Pipelines depends on seeing stage, job, task, or a task shortcut like script as the first key in a mapping.

パイプラインPipeline

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 キーワードを直接指定することができます。If you have a single stage, you can omit the stages keyword and directly specify the jobs keyword:

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

1つのステージと1つのジョブがある場合は、 stages キーワードと jobs キーワードを省略し、 steps キーワードを直接指定できます。If you have a single stage and a single job, you can omit the stages and jobs keywords and directly specify the steps keyword:

# ... 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 キーワードを直接指定することができます。If you have a single job, you can omit the jobs keyword and directly specify the steps keyword:

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

各項目の詳細情報Learn more about:

段階Stage

ステージは、関連するジョブのコレクションです。A stage is a collection of related jobs. 既定では、ステージは順番に実行されます。By default, stages run sequentially. 各ステージは、プロパティで特に指定されていない限り、前のステージが完了した後にのみ開始され dependsOn ます。Each stage starts only after the preceding stage is complete unless otherwise specified via the dependsOn property.

承認チェックを使用して、ステージをいつ実行するかを手動で制御します。Use approval checks to manually control when a stage should run. これらのチェックは、通常、運用環境への配置を制御するために使用されます。These checks are commonly used to control deployments to production environments.

リソース所有者 が使用できるメカニズムを確認します。Checks are a mechanism available to the resource owner. パイプライン内のステージがリソースを使用するタイミングを制御します。They control when a stage in a pipeline consumes a resource. 環境のようなリソースの所有者は、リソースを使用するステージを開始する前に必要なチェックを定義できます。As an owner of a resource like an environment, you can define checks that are required before a stage that consumes the resource can start.

現時点では、手動による承認チェックは 環境でサポートされています。Currently, manual approval checks are supported on environments. 詳細については、「 承認」を参照してください。For more information, see Approvals.

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]

ステージ条件、および変数の詳細については、こちらを参照してください。Learn more about stages, conditions, and variables.

ジョブJob

ジョブは、エージェントまたはサーバーで実行されるステップのコレクションです。A job is a collection of steps run by an agent or on a server. ジョブは 条件 に応じて実行でき、 以前のジョブに依存する場合があります。Jobs can run conditionally and might depend on earlier jobs.

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

クリーンオプションを含むワークスペースの詳細については、「ジョブ」の「ワークスペース」を参照してください。For more information about workspaces, including clean options, see the workspace topic in Jobs.

詳細については、「 変数ステッププール、および サーバージョブ」を参照してください。Learn more about variables, steps, pools, and server jobs.

注意

1つのステージと1つのジョブのみがある場合は、実行する手順を説明するための短い方法として、 単一のジョブの構文 を使用できます。If you have only one stage and one job, you can use single-job syntax as a shorter way to describe the steps to run.

コンテナー参照Container reference

コンテナーはジョブによってサポートされています。A container is supported by jobs.

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

方法Strategies

matrixキーワードと parallel キーワードは、ジョブを複製するための相互排他的な戦略を指定します。The matrix and parallel keywords specify mutually exclusive strategies for duplicating a job.

MatrixMatrix

マトリックスを使用すると、ジョブのコピーが生成され、それぞれの入力が異なります。Use of a matrix generates copies of a job, each with different input. これらのコピーは、さまざまな構成またはプラットフォームのバージョンに対してテストする場合に便利です。These copies are useful for testing against different configurations or platform versions.

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

マトリックスで string1 が出現するたびに、ジョブのコピーが生成されます。For each occurrence of string1 in the matrix, a copy of the job is generated. String1 という名前はコピーの名前で、ジョブの名前に追加されます。The name string1 is the copy's name and is appended to the name of the job. String2 が出現するたびに、値 string3 を持つ string2 という変数をジョブで使用できます。For each occurrence of string2, a variable called string2 with the value string3 is available to the job.

注意

マトリックス構成名には、基本的なラテンアルファベット文字 (A ~ Z と a ~ z)、数字 (0-9)、およびアンダースコア () のみを含める必要があり _ ます。Matrix configuration names must contain only basic Latin alphabet letters (A-Z and a-z), digits (0-9), and underscores (_). 先頭は文字でなければなりません。They must start with a letter. また、長さは100文字以下でなければなりません。Also, their length must be 100 characters or fewer.

省略可能 maxParallel なキーワードでは、同時に実行するマトリックス脚の最大数を指定します。The optional maxParallel keyword specifies the maximum number of simultaneous matrix legs to run at once.

が指定されていない maxParallel か、または0に設定されている場合、制限は適用されません。If maxParallel is unspecified or set to 0, no limit is applied.

が指定されていない場合 maxParallel 、制限は適用されません。If maxParallel is unspecified, no limit is applied.

注意

この構文では自動ジョブスケーリングはサポートされてい matrix ませんが、キーワードを使用して同様の機能を実装でき each ます。The matrix syntax doesn't support automatic job scaling but you can implement similar functionality using the each keyword. 例については、「 」を参照してください。For an example, see expressions.

並列Parallel

この方法では、実行するジョブの重複数を指定します。This strategy specifies how many duplicates of a job should run. これは、大規模なテストマトリックスをスライスする場合に便利です。It's useful for slicing up a large test matrix. Visual Studio のテストタスクでは、スケジュールされたジョブの数に対してテスト負荷を分割する方法を理解します。The Visual Studio Test task understands how to divide the test load across the number of scheduled jobs.

strategy:
  parallel: number

配置ジョブDeployment job

配置ジョブは、特別な種類のジョブです。A deployment job is a special type of job. これは、環境に対して順番に実行する手順のコレクションです。It's a collection of steps to run sequentially against the environment. YAML パイプラインでは、デプロイの手順をデプロイジョブに含めることをお勧めします。In YAML pipelines, we recommend that you put your deployment steps in a deployment job.

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

ステップは、ジョブを構成する一連の操作です。A step is a linear sequence of operations that make up a job. 各ステップは、エージェント上で独自のプロセスで実行され、ローカルハードドライブ上のパイプラインワークスペースにアクセスできます。Each step runs in its own process on an agent and has access to the pipeline workspace on a local hard drive. この動作は、環境変数がステップ間で保持されるのではなく、ファイルシステムの変更があることを意味します。This behavior means environment variables aren't preserved between steps but file system changes are.

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

手順の詳細については、次のスキーマ参照を参照してください。For more information about steps, see the schema references for:

この記事に記載されているかどうかにかかわらず、すべての手順は次のプロパティをサポートしています。All steps, regardless of whether they're documented in this article, support the following properties:

  • displayNamedisplayName
  • namename
  • conditioncondition
  • continueOnErrorcontinueOnError
  • 有効enabled
  • envenv
  • timeoutInMinutestimeoutInMinutes

変数Variables

ハードコーディングされた値を直接追加したり、 変数グループを参照したり、変数テンプレートを使用して挿入したりすることができます。You can add hard-coded values directly, reference variable groups, or insert via variable templates.

パイプライン、ステージ、またはジョブレベルで変数を指定します。Specify variables at the pipeline, stage, or job level.

ハードコーディングされた単純な変数のセットについては、次のマッピング構文を使用します。For a simple set of hard-coded variables, use this mapping syntax:

variables: { string: string }

変数グループを含めるには、次のシーケンス構文に切り替えます。To include variable groups, switch to this sequence syntax:

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

ペアとを繰り返すことができ name / value group ます。You can repeat name/value pairs and group.

変数は、 セキュリティを強化するために読み取り専用として設定することもできます。Variables can also be set as read only to enhance security.

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

テンプレートから変数を含めることもできます。You can also include variables from templates.

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

注意

すべての形式の テンプレート式の完全な構文を確認してください ${{ }}Be sure to see the full template expression syntax, which is all forms of ${{ }}.

パイプラインの再利用可能なセクションを別のファイルにエクスポートできます。You can export reusable sections of your pipeline to a separate file. これらの個別のファイルはテンプレートと呼ばれています。These separate files are known as templates.

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

また、テンプレートを使用して、パイプラインで許可される内容を制御したり、パラメーターを使用する方法を定義したりすることもできます。You can also use templates to control what is allowed in a pipeline and to define how parameters can be used.

パイプラインの再利用可能なセクションを別のファイルにエクスポートできます。You can export reusable sections of your pipeline to separate files. これらの個別のファイルはテンプレートと呼ばれています。These separate files are known as templates. Azure DevOps Server 2019 は、次の2種類のテンプレートをサポートしています。Azure DevOps Server 2019 supports these two kinds of templates:

テンプレート自体に他のテンプレートを含めることができます。Templates themselves can include other templates. Azure Pipelines は、1つのパイプラインで最大50の一意のテンプレートファイルをサポートします。Azure Pipelines supports a maximum of 50 unique template files in a single pipeline.

ステージテンプレートStage templates

1つのファイルで一連のステージを定義し、他のファイルで複数回使用することができます。You can define a set of stages in one file and use it multiple times in other files.

メインパイプラインで、次のようにします。In the main pipeline:

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

含まれているテンプレート:In the included template:

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

ジョブ テンプレートJob templates

1つのファイルで一連のジョブを定義し、他のファイルで複数回使用することができます。You can define a set of jobs in one file and use it multiple times in other files.

メインパイプラインで、次のようにします。In the main pipeline:

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

含まれているテンプレート:In the included template:

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

ジョブテンプレートの操作の詳細については、「 テンプレート 」を参照してください。See templates for more about working with job templates.

ステップテンプレートStep templates

1つのファイルで一連のステップを定義し、別のファイルで複数回使用することができます。You can define a set of steps in one file and use it multiple times in another file.

メインパイプラインで、次のようにします。In the main pipeline:

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

含まれているテンプレート:In the included template:

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

テンプレートの使用の詳細については、「 テンプレート 」を参照してください。See templates for more about working with templates.

変数テンプレートVariable templates

1つのファイルで一連の変数を定義し、他のファイルで複数回使用することができます。You can define a set of variables in one file and use it multiple times in other files.

メインパイプラインで、次のようにします。In the main pipeline:

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

含まれているテンプレート:In the included template:

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

注意

variablesキーワードでは、シーケンスとマッピングという2つの構文形式が使用されます。The variables keyword uses two syntax forms: sequence and mapping. マッピング構文では、すべてのキーは変数名で、値は変数の値です。In mapping syntax, all keys are variable names and their values are variable values. 変数テンプレートを使用するには、sequence 構文を使用する必要があります。To use variable templates, you must use sequence syntax. シーケンス構文では、変数 ( name )、変数グループ ( group )、またはテンプレート () のどちらを使用するかを指定する必要があり template ます。Sequence syntax requires you to specify whether you're mentioning a variable (name), a variable group (group), or a template (template). 詳細については、「 変数 」を参照してください。See the variables topic for more.

パラメーターParameters

テンプレートとパイプラインでパラメーターを使用できます。You can use parameters in templates and pipelines.

パラメーターを定義するときは、型と名前のフィールドが必要です。The type and name fields are required when defining parameters. すべての パラメーターのデータ型を参照してください。See all parameter data types.

parameters:
- name: string          # name of the parameter; required
  type: enum            # data types, see below
  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)

種類Types

データ型Data type メモNotes
string stringstring
number はに制限される場合があります。それ以外の場合は values: 、任意の数字に似た文字列が許容されますmay be restricted to values:, otherwise any number-like string is accepted
boolean true または falsetrue or false
object 任意の YAML 構造体any YAML structure
step 1つの手順a single step
stepList 一連の 手順sequence of steps
job 1つのジョブa single job
jobList ジョブのシーケンスsequence of jobs
deployment 単一の展開ジョブa single deployment job
deploymentList 配置ジョブのシーケンスsequence of deployment jobs
stage 1つのステージa single stage
stageList 一連の ステージsequence of stages

ステップ、stepList、job、jobList、deployment、deploymentList、stage、および stageList の各データ型はすべて、標準の YAML スキーマ形式を使用します。The step, stepList, job, jobList, deployment, deploymentList, stage, and stageList data types all use standard YAML schema format. この例には、文字列、数値、ブール値、オブジェクト、ステップ、および stepList が含まれています。This example includes string, number, boolean, object, step, and 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 }}

リソースResources

リソースとは、パイプラインの一部として使用される外部サービスのことです。A resource is any external service that is consumed as part of your pipeline. リソースの例としては、次のように生成される別の CI/CD パイプラインがあります。An example of a resource is another CI/CD pipeline that produces:

  • Azure Pipelines や Jenkins などの成果物。Artifacts like Azure Pipelines or Jenkins.
  • GitHub、Azure Repos、Git などのコードリポジトリ。Code repositories like GitHub, Azure Repos, or Git.
  • Azure Container Registry や Docker hub などのコンテナーイメージレジストリ。Container-image registries like Azure Container Registry or Docker hub.

YAML のリソースは、パイプライン、コンテナー、リポジトリ、および種類のソースを表します。Resources in YAML represent sources of pipelines, containers, repositories, and types. リソースの詳細については、 こちらを参照してくださいFor more information on Resources, see here.

一般スキーマGeneral schema

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

パイプラインリソースPipeline resource

アーティファクトを生成する Azure パイプラインがある場合、パイプラインは、キーワードを使用して pipeline パイプラインリソースを定義することで、成果物を使用できます。If you have an Azure pipeline that produces artifacts, your pipeline can consume the artifacts by using the pipeline keyword to define a pipeline resource. パイプライン完了トリガーを有効にすることもできます。You can also enable pipeline-completion triggers.

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; 
      stages: [ string ] # list of stages to evaluate for trigger event, optional; 

重要

リソーストリガーを定義すると、そのパイプラインリソースが現在のパイプラインと同じリポジトリからのものである場合、トリガーは、イベントが発生したときと同じ分岐とコミットに従います。When you define a resource trigger, if its pipeline resource is from the same repo as the current pipeline, triggering follows the same branch and commit on which the event is raised. ただし、パイプラインリソースが別のリポジトリからのものである場合、[手動およびスケジュールされた ビルドの既定のブランチ ] 設定によって指定された分岐で現在のパイプラインがトリガーされます。But if the pipeline resource is from a different repo, the current pipeline is triggered on the branch specified by the Default branch for manual and scheduled builds setting. 詳細については、「 パイプライン完了トリガーの分岐に関する考慮事項」を参照してください。For more information, see Branch considerations for pipeline completion triggers.

定義済みの変数としてのパイプラインリソースメタデータThe pipeline resource metadata as predefined variables

実行のたびに、パイプラインリソースのメタデータは、次の定義済みの変数としてすべてのジョブで使用できます。In each run, the metadata for a pipeline resource is available to all jobs as these predefined variables:

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 ます。You can consume artifacts from a pipeline resource by using a download task. ダウンロードキーワードを参照してください。See the download keyword.

コンテナーリソースContainer resource

コンテナージョブ を使用すると、コンテナー内のツールと依存関係を分離できます。Container jobs let you isolate your tools and dependencies inside a container. エージェントは、指定されたコンテナーのインスタンスを起動し、その中でステップを実行します。The agent launches an instance of your specified container then runs steps inside it. キーワードを使用 container すると、コンテナーイメージを指定できます。The container keyword lets you specify your container images.

サービスコンテナー は、データベースなどのさまざまな依存関係を提供するために、ジョブと共に実行されます。Service containers run alongside a job to provide various dependencies like databases.

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 resource

パイプラインに別の リポジトリのテンプレートが含まれている場合は、そのリポジトリについてシステムに通知する必要があります。If your pipeline has templates in another repository, you must let the system know about that repository. repositoryキーワードを使用すると、外部リポジトリを指定できます。The repository keyword lets you specify an external repository.

パイプラインに別の リポジトリ内のテンプレートがある場合、またはサービス接続を必要とするリポジトリで 複数リポジトリのチェックアウト を使用する場合は、そのリポジトリに関する情報をシステムに知らせる必要があります。If your pipeline has templates in another repository, or if you want to use multi-repo checkout with a repository that requires a service connection, you must let the system know about that repository. repositoryキーワードを使用すると、外部リポジトリを指定できます。The repository keyword lets you specify an external 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

TypeType

パイプラインは、、、およびの各リポジトリの種類に対して次の値をサポートし git github bitbucket ます。Pipelines support the following values for the repository type: git, github, and bitbucket. この git 型は Azure Repos Git リポジトリを参照します。The git type refers to Azure Repos Git repos.

  • を指定した場合、 type: git name 値は同じプロジェクト内の別のリポジトリを参照します。If you specify type: git, the name value refers to another repository in the same project. たとえば name: otherRepo です。An example is name: otherRepo. 同じ組織内の別のプロジェクト内のリポジトリを参照するには、名前の前にそのプロジェクトの名前を付けます。To refer to a repo in another project within the same organization, prefix the name with that project's name. たとえば name: OtherProject/otherRepo です。An example is name: OtherProject/otherRepo.

  • を指定した場合、 type: github name 値は GitHub リポジトリの完全な名前になり、ユーザーまたは組織が含まれます。If you specify type: github, the name value is the full name of the GitHub repo and includes the user or organization. たとえば name: Microsoft/vscode です。An example is name: Microsoft/vscode. GitHub リポジトリには、承認のために github サービス接続 が必要です。GitHub repos require a GitHub service connection for authorization.

  • を指定した場合、 type: bitbucket name 値は Bitbucket Cloud リポジトリの完全な名前になり、ユーザーまたは組織が含まれます。If you specify type: bitbucket, the name value is the full name of the Bitbucket Cloud repo and includes the user or organization. たとえば name: MyBitbucket/vscode です。An example is name: MyBitbucket/vscode. Bitbucket cloud リポジトリには、承認のために Bitbucket cloud サービス接続 が必要です。Bitbucket Cloud repos require a Bitbucket Cloud service connection for authorization.

パッケージリソースPackages resource

NuGet および npm GitHub パッケージは、YAML パイプラインのリソースとして使用できます。You can consume NuGet and npm GitHub packages as a resource in YAML pipelines. パッケージリソースを指定する場合は、パッケージをまたはとして設定し NuGet npm ます。When specifying package resources, set the package as NuGet or 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

トリガーTriggers

注意

トリガーブロックには、変数またはテンプレート式を含めることはできません。Trigger blocks can't contain variables or template expressions.

プッシュ トリガーPush trigger

プッシュトリガーでは、継続的インテグレーションビルドを実行する分岐を指定します。A push trigger specifies which branches cause a continuous integration build to run. プッシュトリガーが指定されていない場合、分岐にプッシュすると、ビルドがトリガーされます。If you specify no push trigger, pushes to any branch trigger a build. トリガーとその指定方法の詳細については、こちらを参照してください。Learn more about triggers and how to specify them.

キーワードには3つの異なる構文オプションがあり trigger ます。含める分岐のリスト、CI トリガーを無効にする方法、完全な制御の完全な構文です。There are three distinct syntax options for the trigger keyword: a list of branches to include, a way to disable CI triggers, and the full syntax for complete control.

リスト構文:List syntax:

trigger: [ string ] # list of branch names

無効化構文:Disablement syntax:

trigger: none # will disable CI builds entirely

完全な構文:Full syntax:

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 ます。If you specify an exclude clause without an include clause for branches, tags, or paths, it is equivalent to specifying * in the include clause.

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

重要

トリガーを指定すると、包含するように明示的に構成したブランチだけがパイプラインをトリガーします。When you specify a trigger, only branches that you explicitly configure for inclusion trigger a pipeline. インクルードは最初に処理された後、除外はそのリストから削除されます。Inclusions are processed first, and then exclusions are removed from that list. 除外を指定しても、包含は指定しなかった場合は、何もトリガーしません。If you specify an exclusion but no inclusions, nothing triggers.

PR トリガーPR trigger

プル要求のトリガーは、プル要求のビルドを実行する分岐を指定します。A pull request trigger specifies which branches cause a pull request build to run. プル要求のトリガーを指定しない場合、すべての分岐にプル要求を実行すると、ビルドがトリガーされます。If you specify no pull request trigger, pull requests to any branch trigger a build. プル要求トリガーとその指定方法の詳細については、こちらを参照してください。Learn more about pull request triggers and how to specify them.

重要

YAML PR トリガーは、GitHub と Bitbucket Cloud でのみサポートされています。YAML PR triggers are supported only in GitHub and Bitbucket Cloud. Azure Repos Git を使用する場合は、ビルド 検証用の分岐ポリシー を構成して、検証のためにビルドパイプラインをトリガーすることができます。If you use Azure Repos Git, you can configure a branch policy for build validation to trigger your build pipeline for validation.

重要

YAML PR トリガーは、GitHub でのみサポートされています。YAML PR triggers are supported only in GitHub. Azure Repos Git を使用する場合は、ビルド 検証用の分岐ポリシー を構成して、検証のためにビルドパイプラインをトリガーすることができます。If you use Azure Repos Git, you can configure a branch policy for build validation to trigger your build pipeline for validation.

キーワードには3つの異なる構文オプションがあり pr ます。含める分岐のリスト、PR トリガーを無効にする方法、および完全な制御の完全な構文です。There are three distinct syntax options for the pr keyword: a list of branches to include, a way to disable PR triggers, and the full syntax for complete control.

リスト構文:List syntax:

pr: [ string ] # list of branch names

無効化構文:Disablement syntax:

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

完全な構文:Full syntax:

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 ます。If you specify an exclude clause without an include clause for branches or paths, it is equivalent to specifying * in the include clause.

重要

プル要求のトリガーを指定すると、包含するように明示的に構成したブランチだけがパイプラインをトリガーします。When you specify a pull request trigger, only branches that you explicitly configure for inclusion trigger a pipeline. インクルードは最初に処理された後、除外はそのリストから削除されます。Inclusions are processed first, and then exclusions are removed from that list. 除外を指定しても、包含は指定しなかった場合は、何もトリガーしません。If you specify an exclusion but no inclusions, nothing triggers.

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

YAML のスケジュールされたトリガーは、このバージョンの Azure DevOps Server または Visual Studio Team Foundation Server では使用できません。YAML scheduled triggers are unavailable in either this version of Azure DevOps Server or Visual Studio Team Foundation Server. スケジュールされた トリガーは、クラシックエディターで使用できます。You can use scheduled triggers in the classic editor.

スケジュールされたトリガーでは、分岐を作成するスケジュールを指定します。A scheduled trigger specifies a schedule on which branches are built. スケジュールされたトリガーを指定しない場合、スケジュールされたビルドは実行されません。If you specify no scheduled trigger, no scheduled builds occur. スケジュールされた トリガー とその指定方法の詳細については、こちらを参照してください。Learn more about scheduled triggers and how to specify them.

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 ます。If you specify an exclude clause without an include clause for branches, it is equivalent to specifying * in the include clause.

パイプライントリガーPipeline trigger

パイプラインの完了トリガーは、 パイプラインリソースを使用して構成されます。Pipeline completion triggers are configured using a pipeline resource. 詳細については、「 パイプライン完了トリガー」を参照してください。For more information, see Pipeline completion triggers.

プールPool

キーワードは、 pool パイプラインのジョブに使用する プール を指定します。The pool keyword specifies which pool to use for a job of the pipeline. また、仕様には pool 、を実行するためのジョブの戦略に関する情報も保持されます。A pool specification also holds information about the job's strategy for running.

Azure DevOps Server 2019 では、YAML のジョブレベルでプールを指定し、パイプラインの設定 UI でパイプラインレベルでプールを指定できます。In Azure DevOps Server 2019 you can specify a pool at the job level in YAML, and at the pipeline level in the pipeline settings UI. Azure DevOps Server 2019.1 では、1つの暗黙的なジョブがある場合は、YAML のパイプラインレベルでプールを指定することもできます。In Azure DevOps Server 2019.1 you can also specify a pool at the pipeline level in YAML if you have a single implicit job.

パイプライン、ステージ、またはジョブレベルでプールを指定できます。You can specify a pool at the pipeline, stage, or job level.

階層の最下位レベルで指定されたプールは、ジョブの実行に使用されます。The pool specified at the lowest level of the hierarchy is used to run the job.

完全な構文は次のとおりです。The full syntax is:

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 がホストするプールを使用する場合は、 使用可能な仮想マシンイメージを選択します。If you use a Microsoft-hosted pool, choose an available virtual machine image.

プライベートプールを使用し、要求を指定する必要がない場合は、構文を次のように短縮できます。If you use a private pool and don't need to specify demands, you can shorten the syntax to:

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

条件タイムアウトの詳細についてはこちらをご覧ください。Learn more about conditions and timeouts.

確認要求Demands

キーワードは、 demands プライベートプールでサポートされています。The demands keyword is supported by private pools. 機能または特定の文字列が存在するかどうかを確認できます。You can check for the existence of a capability or a specific string.

pool:
  demands: [ string ]

環境Environment

キーワードは、 environment パイプラインの配置ジョブの対象となる 環境 またはそのリソースを指定します。The environment keyword specifies the environment or its resource that is targeted by a deployment job of the pipeline. また、環境には、ジョブ内で定義されているステップを実行するための配置方法に関する情報も保持されます。An environment also holds information about the deployment strategy for running the steps defined inside the job.

完全な構文は次のとおりです。The full syntax is:

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つを指定し、他のプロパティを指定する必要がない場合は、構文を次のように短縮できます。If you specify an environment or one of its resources but don't need to specify other properties, you can shorten the syntax to:

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

サーバーServer

この server 値は、 サーバージョブを指定します。The server value specifies a server job. サーバージョブで実行できるのは、 Azure function app の呼び出し などのサーバータスクだけです。Only server tasks like invoking an Azure function app can be run in a server job.

を使用すると server 、ジョブはエージェントジョブではなく、サーバージョブとして実行されます。When you use server, a job runs as a server job rather than an agent job.

pool: server

スクリプトScript

scriptキーワードは、コマンドラインタスクのショートカットです。The script keyword is a shortcut for the command-line task. このタスクは、Windows では cmd.exe を使用し、他のプラットフォームでは Bash を使用してスクリプトを実行します。The task runs a script using cmd.exe on Windows and Bash on other platforms.

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 次のように構造を短くすることができます。If you don't specify a command mode, you can shorten the target structure to:

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

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。Learn more about conditions, timeouts, and step targets.

BashBash

bashキーワードは、シェルスクリプトタスクのショートカットです。The bash keyword is a shortcut for the shell script task. このタスクは、Windows、macOS、Linux の Bash でスクリプトを実行します。The task runs a script in Bash on Windows, macOS, and Linux.

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 次のように構造を短くすることができます。If you don't specify a command mode, you can shorten the target structure to:

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

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。Learn more about conditions, timeouts, and step targets.

pwshpwsh

キーワードは、 pwsh そのタスクの pwsh 値が true に設定されている場合の PowerShell タスクのショートカットです。The pwsh keyword is a shortcut for the PowerShell task when that task's pwsh value is set to true. このタスクは、Windows、macOS、および Linux 上の PowerShell Core でスクリプトを実行します。The task runs a script in PowerShell Core on Windows, macOS, and Linux.

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 セッションは、ジョブが実行されている間だけ継続されます。Each PowerShell session lasts only for the duration of the job in which it runs. ブートストラップの内容に依存するタスクは、ブートストラップと同じジョブ内に存在する必要があります。Tasks that depend on what has been bootstrapped must be in the same job as the bootstrap.

条件タイムアウトの詳細についてはこちらをご覧ください。Learn more about conditions and timeouts.

PowerShellPowerShell

powershellキーワードは、 PowerShell タスクのショートカットです。The powershell keyword is a shortcut for the PowerShell task. このタスクは、Windows PowerShell でスクリプトを実行します。The task runs a script in 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 セッションは、ジョブが実行されている間だけ継続されます。Each PowerShell session lasts only for the duration of the job in which it runs. ブートストラップの内容に依存するタスクは、ブートストラップと同じジョブ内に存在する必要があります。Tasks that depend on what has been bootstrapped must be in the same job as the bootstrap.

条件タイムアウトの詳細についてはこちらをご覧ください。Learn more about conditions and timeouts.

エラーアクションの設定Error action preference

特に指定しない限り、[エラーアクション] 設定は既定値に設定され、 stop$ErrorActionPreference = 'stop' はスクリプトの先頭に付加されます。Unless otherwise specified, the error action preference defaults to the value stop, and the line $ErrorActionPreference = 'stop' is prepended to the top of your script.

エラーアクションの設定が [停止] に設定されている場合、エラーが発生すると、PowerShell によってタスクが終了し、0以外の終了コードが返されます。When the error action preference is set to stop, errors cause PowerShell to terminate the task and return a nonzero exit code. タスクも失敗としてマークされています。The task is also marked as Failed.

errorActionPreference: stop | continue | silentlyContinue

最後の終了コードを無視するIgnore last exit code

スクリプトから返された最後の終了コードは、既定ではオンになっています。The last exit code returned from your script is checked by default. 0以外のコードはステップが失敗したことを示します。この場合、システムは次のようにスクリプトを追加します。A nonzero code indicates a step failure, in which case the system appends your script with:

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

この動作が不要な場合は、を指定し ignoreLASTEXITCODE: true ます。If you don't want this behavior, specify ignoreLASTEXITCODE: true.

ignoreLASTEXITCODE: boolean

条件タイムアウトの詳細についてはこちらをご覧ください。Learn more about conditions and timeouts.

発行Publish

publishキーワードは、パイプラインアーティファクトの発行タスクのショートカットです。The publish keyword is a shortcut for the Publish Pipeline Artifact task. このタスクは、他のジョブやパイプラインが使用できるパイプラインアーティファクトとしてファイルまたはフォルダーを発行 (アップロード) します。The task publishes (uploads) a file or folder as a pipeline artifact that other jobs and pipelines can consume.

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

成果物の公開についての詳細情報。Learn more about publishing artifacts.

ダウンロードDownload

downloadキーワードは、パイプラインアーティファクトのダウンロードタスクのショートカットです。The download keyword is a shortcut for the Download Pipeline Artifact task. このタスクは、現在の実行に関連付けられている成果物、またはパイプラインリソースとして関連付けられている別の Azure パイプラインからの成果物をダウンロードします。The task downloads artifacts associated with the current run or from another Azure pipeline that is associated as a pipeline resource.

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

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

現在のパイプラインからの成果物は、$ (pipeline. Workspace)/にダウンロードされ ます。Artifacts from the current pipeline are downloaded to $(Pipeline.Workspace)/.

関連付けられているパイプラインリソースの成果物は、$ (pipeline. Workspace)/にダウンロードされ <pipeline resource identifier> / ます。Artifacts from the associated pipeline resource are downloaded to $(Pipeline.Workspace)/<pipeline resource identifier>/.

デプロイジョブでの自動ダウンロードAutomatic download in deployment jobs

現在のパイプラインおよび関連するパイプラインリソースから使用可能なすべてのアイテムは、デプロイジョブに自動的にダウンロードされ、デプロイに使用できるようになります。All available artifacts from the current pipeline and from the associated pipeline resources are automatically downloaded in deployment jobs and made available for your deployment. ダウンロードが行われないようにするには、を指定し download: none ます。To prevent downloads, specify download: none.

アーティファクトのダウンロードに関する詳細情報。Learn more about downloading artifacts.

チェックアウトCheckout

配置以外のジョブでは、ソースコードが自動的にチェックアウトされます。Nondeployment jobs automatically check out source code. checkoutこの動作を構成または非表示にするには、キーワードを使用します。Use the checkout keyword to configure or suppress this behavior.

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; 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 、ワークスペースでクリーニングを構成することもできます。In addition to the cleaning option available using checkout, you can also configuring cleaning in a workspace. クリーンオプションを含むワークスペースの詳細については、「ジョブ」の「ワークスペース」を参照してください。For more information about workspaces, including clean options, see the workspace topic in Jobs.

ソースの同期をまったく行わないようにするには:To avoid syncing sources at all:

steps:
- checkout: none

注意

ローカルサービスアカウントでエージェントを実行していて、git 操作を使用して現在のリポジトリを変更する場合、または git サブモジュールを読み込む場合は、プロジェクトコレクションビルドサービスアカウントユーザーに適切なアクセス許可を付与します。If you're running the agent in the Local Service account and want to modify the current repository by using git operations or loading git submodules, give the proper permissions to the Project Collection Build Service Accounts user.

- checkout: self
  submodules: true
  persistCredentials: true

パイプラインで複数のリポジトリをチェックアウトするには、複数の手順を使用し checkout ます。To check out multiple repositories in your pipeline, use multiple checkout steps:

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

詳細については、「 パイプラインで複数のリポジトリをチェックアウトする」を参照してください。For more information, see Check out multiple repositories in your pipeline.

タスクTask

タスク は、パイプラインの構成要素です。Tasks are the building blocks of a pipeline. 選択できる タスクのカタログ があります。There's a catalog of tasks available to choose from.

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 次のように構造を短くすることができます。If you don't specify a command mode, you can shorten the target structure to:

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

詳細については、 条件タイムアウトステップターゲットに関するページを参照してください。Learn more about conditions, timeouts, and step targets.

構文の強調表示Syntax highlighting

構文の強調表示は、パイプラインスキーマで Visual Studio Code 拡張機能を使用して利用できます。Syntax highlighting is available for the pipeline schema via a Visual Studio Code extension. Visual Studio Code を ダウンロードして 拡張機能をインストールし、 GitHub でプロジェクトを確認できます。You can download Visual Studio Code, install the extension, and check out the project on GitHub. 拡張機能には、検証用の JSON スキーマ が含まれています。The extension includes a JSON schema for validation.

また、 Azure DevOps REST API yamlschema エンドポイントから、組織に固有のスキーマ (インストールされているカスタムタスクを含む) を取得することもできます。You also can obtain a schema that's specific to your organization (that is, it contains installed custom tasks) from the Azure DevOps REST API yamlschema endpoint.