パイプラインにジョブを指定する

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

注意

Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。

パイプラインをジョブにまとめることができます。 すべてのパイプラインには、少なくとも1つのジョブがあります。 ジョブとは、連続して1つの単位として実行される一連の手順です。 つまり、ジョブは、実行するようにスケジュールできる最小の作業単位です。

ビルドまたはリリースパイプラインをジョブにまとめることができます。 すべてのパイプラインには、少なくとも1つのジョブがあります。 ジョブとは、連続して1つの単位として実行される一連の手順です。 つまり、ジョブは、実行するようにスケジュールできる最小の作業単位です。

注意

ビルドプロセスでジョブを使用するには、TFS 2018.2 をインストールする必要があります。 TFS 2018 RTM では、リリースの配置プロセスでジョブを使用できます。

リリースパイプラインをジョブにまとめることができます。 すべてのリリースパイプラインには、少なくとも1つのジョブがあります。 このバージョンの TFS のビルドパイプラインでは、ジョブはサポートされていません。

注意

TFS 2017 のリリースパイプラインでジョブを使用するには、Update 2 をインストールする必要があります。 ビルドパイプラインのジョブは、Azure Pipelines、TFS 2018.2、およびそれ以降のバージョンで使用できます。

1つのジョブを定義する

最も単純なケースでは、パイプラインには1つのジョブがあります。 この場合、テンプレートを使用しない限り、キーワードを明示的に使用する必要はありません job YAML ファイルの手順を直接指定できます。

この YAML ファイルには、Microsoft がホストする エージェント と出力で実行されるジョブがあり Hello world ます。

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

そのジョブに追加のプロパティを指定することもできます。 その場合は、キーワードを使用でき job ます。

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

パイプラインに複数のジョブがある場合があります。 その場合は、キーワードを使用し jobs ます。

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

パイプラインには複数のステージがあり、それぞれに複数のジョブがあります。 その場合は、キーワードを使用し stages ます。

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

ジョブを指定する完全な構文は次のとおりです。

- 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
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  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: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

ジョブを指定する完全な構文は次のとおりです。

- 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
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  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: { string: string } | [ variable | variableReference ] 
  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

ジョブの主な目的が (アプリをビルドまたはテストするのではなく) アプリをデプロイする場合は、 デプロイジョブ と呼ばれる特別な種類のジョブを使用できます。

デプロイジョブの構文は次のとおりです。

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

で展開タスクのステップを追加することもでき job ますが、代わりに 配置ジョブを使用することをお勧めします。 デプロイジョブにはいくつかの利点があります。 たとえば、環境に配置できます。これには、デプロイした内容の履歴を表示できるなどの利点があります。

YAML は、このバージョンの TFS ではサポートされていません。

ジョブの種類

ジョブの種類は、実行場所によって異なる場合があります。

  • エージェント プールジョブ は、エージェントプール内のエージェントで実行されます。
  • サーバージョブ は Azure DevOps Server で実行されます。
  • コンテナージョブ は、エージェントプール内のエージェントのコンテナーで実行されます。 コンテナーの選択の詳細については、「 定義 (コンテナージョブを)」を参照してください。
  • エージェント プールジョブ は、エージェントプール内のエージェントで実行されます。
  • サーバージョブ は Azure DevOps Server で実行されます。
  • エージェント プールジョブ は、エージェントプールのエージェントで実行されます。 これらのジョブは、ビルドおよびリリースパイプラインで利用できます。
  • サーバージョブ は TFS 上で実行されます。 これらのジョブは、ビルドおよびリリースパイプラインで利用できます。
  • 配置 グループジョブ は、配置グループ内のコンピューター上で実行されます。 これらのジョブは、リリースパイプラインでのみ使用できます。
  • エージェント プールジョブ は、エージェントプールのエージェントで実行されます。 これらのジョブは、利用可能なリリースパイプラインのみです。

エージェントプールジョブ

これらは最も一般的な種類のジョブで、エージェントプールのエージェントで実行されます。

  • Microsoft がホストするエージェントを使用する場合、パイプライン内の各ジョブは、新しいエージェントを取得します。
  • エージェントがジョブを実行するために必要な機能を指定するには、自己ホスト型エージェントで 要求 を使用します。 パイプラインの要求に一致するエージェントがエージェントプールに複数存在するかどうかによって、連続するジョブに対して同じエージェントを取得できます。 パイプラインの要求に一致するエージェントがプール内に1つしかない場合、パイプラインはこのエージェントが使用可能になるまで待機します。

注意

要求と機能は、ジョブの要件を満たすエージェントとジョブを照合できるように、自己ホスト型エージェントで使用するように設計されています。 Microsoft がホストするエージェントを使用する場合は、ジョブの要件に一致するエージェントのイメージを選択します。そのため、Microsoft がホストするエージェントに機能を追加することはできますが、Microsoft がホストするエージェントで機能を使用する必要はありません。

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

または複数の要求:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

YAML は、TFS ではまだサポートされていません。

エージェントの機能の詳細については、こちらをご覧ください。

サーバージョブ

サーバージョブのタスクは、によって調整され、サーバー (Azure Pipelines または TFS) で実行されます。 サーバージョブには、エージェントまたはターゲットコンピューターは必要ありません。 現在のサーバージョブでは、いくつかのタスクのみがサポートされています。

エージェントレスジョブでサポートされるタスク

現時点では、エージェントレスジョブでは、次のタスクのみが既定でサポートされています。

タスクは拡張可能なので、拡張機能を使用してエージェントレス タスクを追加できます。 エージェントレス ジョブの既定のタイムアウトは 60 分です。

サーバー ジョブを指定するための完全な構文は次のとおりです。

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server

簡略化された構文を使用することもできます。

jobs:
- job: string
  pool: server

YAML は TFS ではまだサポートされていません。

依存関係

1 つのステージで複数のジョブを定義する場合は、その間の依存関係を指定できます。 Pipelines、依存関係がないジョブを少なくとも 1 つ含む必要があります。

注意

各エージェントは、一度に 1 つのジョブのみを実行できます。 複数のジョブを並列で実行するには、複数のエージェントを構成する必要があります。 また、十分な並列ジョブ も必要です

複数のジョブとその依存関係を定義するための構文は次のとおりです。

jobs:
- job: string
  dependsOn: string
  condition: string

順次ビルドするジョブの例:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

並列でビルドするジョブの例 (依存関係なし):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

ファンアウトの例:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

ファンインの例:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

YAML ビルドは TFS ではまだ使用できません。

条件

各ジョブを実行する条件を指定できます。 既定では、ジョブは、他のジョブに依存しない場合、または依存しているすべてのジョブが完了して成功した場合に実行されます。 この動作をカスタマイズするには、前のジョブが失敗した場合でも、またはカスタム条件を指定してジョブを実行します。

前のジョブの実行状態に基づいてジョブを実行する例:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

カスタム条件の使用 :

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/master'))
  steps:
  - script: echo this only runs for master

前のジョブで設定された出力変数の値に基づいてジョブを実行できます。 この場合、直接依存ジョブで設定された変数のみを使用できます。

jobs:
- job: A
  steps:
  - script: "echo ##vso[task.setvariable variable=skipsubsequent;isOutput=true]false"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

YAML ビルドは TFS ではまだ使用できません。

Timeouts

ジョブが応答しない場合や待ち時間が長すぎる場合にリソースを使用しないようにするには、ジョブの実行を許可する期間に制限を設定します。 ジョブタイムアウト設定を使用して、ジョブを実行する制限を分で指定します。 値を 0 に 設定すると 、ジョブを実行できます。

  • セルフホステッド エージェントでいつまでも
  • パブリック プロジェクトとパブリック リポジトリを使用する Microsoft ホステッド エージェントでの 360 分間 (6 時間)
  • プライベート プロジェクトまたはプライベート リポジトリを使用する Microsoft ホステッド エージェントで 60 分間 (追加の容量が支払われる場合を含む)

タイムアウト期間は、ジョブの実行が開始されると開始されます。 ジョブがキューに入っている時間やエージェントを待機している時間は含まれます。

timeoutInMinutes 使用すると、ジョブの実行時間に制限を設定できます。 指定しない場合、既定値は 60 分です。 を 0 指定すると、上限が使用されます (前述)。

を使用すると、前のタスクが失敗した場合に実行を続ける展開タスクが設定されている場合に、ジョブの取り消し時間に制限 cancelTimeoutInMinutes を設定できます。 指定しない場合、既定値は 5 分です。 値は 1 ~ 35790 分の範囲である必要 があります。

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

YAML は TFS ではまだサポートされていません。

Microsoft ホステッド エージェントを対象とする ジョブには、 実行できる期間に関する追加の制限があります。

各タスクのタイムアウトを個別に設定できます。タスク制御オプションに関 するページを参照してください

複数ジョブの構成

作成した 1 つのジョブから、複数のエージェントで複数のジョブを並列で実行できます。 次に例をいくつか示します。

  • マルチ構成ビルド: 複数の構成を並列でビルドできます。 たとえば、 と の両方のプラットフォームVisual C++ debug アプリをビルド release x86 x64 できます。 詳細については、「複数のプラットフォームVisual Studioビルド - 複数の構成」を参照してください

  • 複数構成のデプロイ: たとえば、異なる地理的リージョンに対して、複数のデプロイを並列で実行できます。

  • マルチ構成テスト: 複数の構成のテストを並列で実行できます。

  • マルチ構成変数が空の場合でも、マルチ構成では常に少なくとも 1 つのジョブが生成されます。

この matrix 方法を使用すると、異なる変数セットを使用してジョブを複数回ディスパッチできます。 タグ maxParallel は並列処理の量を制限します。 次のジョブは、Location と Browser の値が指定に設定された 3 回ディスパッチされます。 ただし、同時に実行されるジョブは 2 つのみです。

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

注意

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

出力変数を使用して マトリックスを 生成する方法も可能です。 これは、スクリプトを使用してマトリックスを生成する必要がある場合に便利です。

matrix は、文字列化された JSON オブジェクトを含むランタイム式を受け取ります。 展開された JSON オブジェクトは、行列構文と一致する必要があります。 次の例では、JSON 文字列をハードコードしましたが、スクリプト言語またはコマンドライン プログラムによって生成される可能性があります。

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

YAML は TFS ではサポートされていません。

スライス

エージェント ジョブを使用して、一スイートのテストを並列で実行できます。 たとえば、1 つのエージェントで 1,000 テストの大規模なスイートを実行できます。 または、2 つのエージェントを使用し、それぞれに対して 500 のテストを並列で実行できます。

スライスを利用するには、ジョブ内のタスクが属するスライスを理解するのに十分なスマートである必要があります。

テスト Visual Studioタスクは、テスト スライスをサポートするそのようなタスクの 1 つです。 複数のエージェントをインストールしている場合は、これらのエージェントで Visual Studioテスト タスクを並列実行する方法を指定できます。

この parallel 戦略により、ジョブを何度も複製できます。 変数 System.JobPositionInPhase と は System.TotalJobsInPhase 、各ジョブに追加されます。 その後、スクリプト内で変数を使用して、ジョブ間で作業を分割できます。 「 エージェント ジョブを使用した並列実行と複数実行」を参照してください

次のジョブは、 と の値を使用して 5 回 System.JobPositionInPhase ディスパッチされ、適切 System.TotalJobsInPhase に設定されます。

jobs:
- job: Test
  strategy:
    parallel: 5

YAML は TFS ではまだサポートされていません。

ジョブ変数

YAML を使用している場合は、ジョブで変数を指定できます。 変数は、マクロ構文 $(variableName) を使用してタスク入力に渡したり、ステージ変数を使用してスクリプト内でアクセスしたりできます。

ジョブで変数を定義し、それらをタスク内で使用する例を次に示します。

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

YAML は TFS ではまだサポートされていません。

条件 の使用の 詳細については、「 条件の指定 」を参照してください

ワークスペース

エージェント プール ジョブを実行すると、エージェントにワークスペースが作成されます。 ワークスペースは、ソースをダウンロードし、ステップを実行して出力を生成するディレクトリです。 ワークスペース ディレクトリは、変数を使用してジョブで参照 Pipeline.Workspace できます。 この下に、さまざまなサブディレクトリが作成されます。

エージェント プール ジョブを実行すると、エージェントにワークスペースが作成されます。 ワークスペースは、ソースをダウンロードし、ステップを実行して出力を生成するディレクトリです。 ワークスペース ディレクトリは、変数を使用してジョブで参照 Agent.BuildDirectory できます。 この下に、さまざまなサブディレクトリが作成されます。

  • Build.SourcesDirectory は、タスクがアプリケーションのソース コードをダウンロードする場所です。
  • Build.ArtifactStagingDirectory は、タスクがパイプラインに必要な成果物をダウンロードする場所、または成果物が発行される前に成果物をアップロードする場所です。
  • Build.BinariesDirectory は、タスクが出力を書き込む場所です。
  • Common.TestResultsDirectory は、タスクがテスト結果をアップロードする場所です。

セルフホステッド エージェント でパイプラインを実行すると、既定では、2 回の連続実行の間にどのサブディレクトリもクリーンアップされません。 その結果、それを利用するためにタスクが実装されている場合は、増分ビルドとデプロイを実行できます。 この動作は、ジョブの 設定 workspace を使用してオーバーライドできます。

重要

ワークスペースのクリーン オプションは、セルフホステッド エージェントにのみ適用されます。 Microsoft ホステッド エージェントを使用する場合、ジョブは常に新しいエージェントで実行されます。

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

オプションのいずれかを指定すると clean 、次のように解釈されます。

  • outputs: 新しい Build.BinariesDirectory ジョブを実行する前に削除します。
  • resources: 新しい Build.SourcesDirectory ジョブを実行する前に削除します。
  • all:新しいジョブを Pipeline.Workspace 実行する前に、ディレクトリ全体を削除します。

$(Build.ArtifactStagingDirectory) と は、これらの設定に関係なく、すべてのビルドの前に常に $(Common.TestResultsDirectory) 削除および再作成されます。

  jobs:
  - deployment: deploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

注意

エージェントの機能とパイプラインの需要に応じて、各ジョブがセルフホステッド プール内の別のエージェントにルーティングされる場合があります。 その結果、後続のパイプラインの実行 (または同じパイプライン内のステージまたはジョブ) の新しいエージェントが取得される可能性があります。そのため、クリーンアップしない場合、後続の実行、ジョブ、またはステージが以前の実行、ジョブ、またはステージからの出力にアクセスできる保証はありません。 エージェントの機能とパイプラインの要求を構成して、パイプライン ジョブの実行に使用するエージェントを指定できますが、プール内に要求を満たすエージェントが 1 つしかない限り、後続のジョブで前のジョブと同じエージェントが使用される保証はありません。 詳細については、「要求の指定 」を参照してください

ワークスペースのクリーンに加えて、パイプライン設定 UI で [ クリーン] 設定を構成して、クリーニングを構成することもできます。 [クリーン ] 設定true の場合 は、パイプラインのすべてのチェックアウト ステップに を clean: true 指定するのと同じです。 [クリーン] 設定 を構成 するには:

  1. パイプラインを編集し、 [...] を選択 し、 [トリガー] を選択します

    トリガーを編集します。

  2. [YAML]、 [ソースの取得] を選択し、目的の [クリーン] 設定 を構成 します。 既定値は false です。

    クリーンな設定。

YAML は TFS ではまだサポートされていません。

成果物のダウンロード

この例の YAML ファイルは成果物を発行し WebSite 、成果物を にダウンロードします $(Pipeline.Workspace) 。 配置ジョブは、ビルド ジョブが成功した場合にのみ実行されます。

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(System.DefaultWorkingDirectory)

  dependsOn: Build
  condition: succeeded()

YAML は TFS ではまだサポートされていません。

dependsOn と conditionの 使用の詳細については、「 条件の指定 」を参照してください

OAuth トークンへのアクセス

ジョブで実行されているスクリプトが、現在のトークンまたは TFS OAuth Azure Pipelinesアクセスを許可できます。 トークンを使用して、トークンに対する認証Azure Pipelines REST API。

OAuth トークンは、YAML パイプラインで常に使用できます。 を使用してタスクまたはステップに明示的にマップする必要があります env 。 次に例を示します。

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

YAML は TFS ではまだサポートされていません。

参照トピック