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

[アーティクル]
04/04/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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

パイプラインを構成する主要な概念とコンポーネントについては、新しい Azure Pipelines ユーザーの主要な概念に関するページを参照してください。

Azure Pipelines では、YAML パイプラインのジョブ優先度はサポートされていません。ジョブの実行タイミングを制御するには、条件と依存関係を指定します。

最もシンプルなケースでは、パイプラインに 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
クラシック

エージェントプールジョブはエージェントプール内のエージェント上で実行されます。
サーバージョブは、Azure DevOps Server で実行されます。
コンテナージョブ は、エージェントプール内のエージェント上のコンテナーで実行されます。コンテナーの選択の詳細については、「コンテナージョブを定義する」を参照してください。

YAML
クラシック

エージェントプールジョブはエージェントプール内のエージェント上で実行されます。
サーバージョブは、Azure DevOps Server で実行されます。

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

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

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

Note

要求と機能はセルフホステッドエージェントで使うように設計されているので、ジョブをジョブの要件を満たすエージェントと対応付けることができます。 Microsoft ホステッドエージェントを使う場合、ジョブの要件に一致するエージェントのイメージはお客様が選ぶので、Microsoft ホステッドエージェントに機能を追加することもできますが、Microsoft ホステッドエージェントで機能を使う必要はありません。

YAML
クラシック

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

詳細については、エージェント機能に関する記事を参照してください。

サーバージョブ

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

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

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

タスクは拡張機能可能であるため、拡張機能を使ってエージェントレスタスクをさらに追加できます。エージェントレスジョブの既定のタイムアウトは 60 分です。

YAML
クラシック

サーバージョブを指定する完全な構文:

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

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

また、簡略化された構文も使用できます。

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

依存関係

1 つのステージで複数のジョブを定義する場合、それらの間の依存関係を指定できます。パイプラインには、依存関係のないジョブを少なくとも 1 つ含める必要があります。既定では、dependsOn 値が設定されている場合を除き、Azure DevOps YAML パイプラインジョブは並列で実行されます。

Note

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

YAML
クラシック

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

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
クラシック

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

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/main'))
  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

Timeouts

ジョブが応答しないときや待機時間が長すぎるときにリソースを占有しないようにするには、ジョブの実行時間に制限を設定することをお勧めします。ジョブのタイムアウト設定を使って、ジョブの実行に関する制限を分単位で指定します。値をゼロに設定した場合、ジョブを実行できる期間は次のとおりです。

セルフホステッドエージェントの場合は永続的
パブリックプロジェクトとパブリックリポジトリを使う Microsoft ホステッドエージェントの場合は 360 分 (6 時間)
プライベートプロジェクトまたはプライベートリポジトリを使う Microsoft ホステッドエージェントの場合は 60 分 (追加容量を購入していない場合)

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

YAML
クラシック

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

配置タスクで前のタスクが失敗した場合に実行を継続するように設定している場合、cancelTimeoutInMinutes を使うと、ジョブのキャンセル時間に制限を設定できます。指定しない場合、既定値は 5 分です。この値の範囲は 1 分から 35,790 分です。

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

タイムアウトには、次のレベルの優先順位があります。

Microsoft ホステッドエージェントでは、ジョブの実行時間は、プロジェクトの種類と、有料の並列ジョブを使用して実行されるかどうかに基づいて制限されます。 Microsoft がホストするジョブのタイムアウト間隔が経過すると、ジョブは終了します。 Microsoft ホステッドエージェントでは、ジョブで指定されたジョブレベルのタイムアウトに関係なく、ジョブをこの間隔より長く実行することはできません。
ジョブレベルで構成されたタイムアウトは、ジョブの実行の最大期間を指定します。ジョブレベルのタイムアウト間隔が経過すると、ジョブは終了します。 Microsoft ホステッドエージェントでジョブを実行する場合、ジョブレベルのタイムアウトを組み込みの Microsoft でホストされているジョブレベルのタイムアウトより大きい間隔に設定しても効果はなく、Microsoft がホストするジョブのタイムアウトが使用されます。
各タスクのタイムアウトを個別に設定することもできます。「タスク制御オプション」をご覧ください。タスクが完了する前にジョブレベルのタイムアウト間隔が経過すると、タスクのタイムアウト間隔が長く構成されている場合でも、実行中のジョブは終了します。

複数ジョブの構成

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

複数構成のビルド: 複数の構成を並列でビルドできます。たとえば、x86 と x64 の両方のプラットフォーム上で debug と release の両方の構成向けに Visual C++ アプリをビルドできます。詳細については、Visual Studio Build - 複数プラットフォーム向けの複数の構成に関する記事を参照してください。
複数構成の配置: 複数の配置を、たとえば異なる地域に対して並列で実行できます。
複数構成のテスト: テスト用の複数の構成を並列で実行できます。
複数構成の場合、複数構成変数が空であっても、少なくとも 1 つのジョブが常に生成されます。

YAML
クラシック

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

Note

(上記の 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

複数構成オプションを使って複数のジョブを実行するには、multiplier (乗数) という変数を指定し、その multiplier の値一覧を指定します。一覧内の各値に対して個別のジョブが実行されます。ビルドまたは配置に multiplier を使うには、次のことを行う必要があります。

パイプラインの [変数] タブまたは変数グループで 1 つ以上の変数を定義します。各変数 (このコンテキストでは multiplier 変数) は、エージェントに個別に渡す値のコンマ区切り一覧として定義する必要があります。
[乗数] パラメーターの値として、$ とかっこを含めずに乗数変数の名前を入力します。シークレット変数を乗数変数として使うことはサポートされていません。
複数の乗数変数に対してジョブを実行する場合は、変数名をコンマ区切りで入力します (それぞれ $ とかっこは省略します)。
配置時に使うエージェント数を、サブスクリプションに構成した数未満に制限する場合は、その値を [エージェントの最大数] パラメーターとして入力します。

たとえば、次のように Location と Browser という 2 つの変数を定義できます。

場所 = US,Europe
Browser = IE,Chrome,Edge,Firefox

次の構成では、一度に最大 4 つのエージェントを使って配置を 8 回実行します。

乗数 = Location,Browser
エージェントの最大数 = 4

複数構成の場合、1 つ以上の変数 (乗数) の値を変えて複数のジョブを実行することができます。複数のエージェントで同じジョブを実行する場合は、並列処理の [複数エージェント] オプションを使用できます。上記のテストスライスの例は、[複数エージェント] オプションを使って実現できます。

スライス

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

スライスを適用するには、ジョブ内のタスクに、その属するスライスを理解できる高い機能が必要です。

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

YAML
クラシック

parallel 戦略を使うと、ジョブを何度も複製できます。変数 System.JobPositionInPhase と System.TotalJobsInPhase が各ジョブに追加されます。この変数をスクリプト内で使うことで、作業を複数のジョブに分割できます。エージェントジョブを使った並列および複数の実行に関する記事を参照してください。

次のジョブは 5 回ディスパッチされます。その際に System.JobPositionInPhase と System.TotalJobsInPhase の値は適切に設定されます。

jobs:
- job: Test
  strategy:
    parallel: 5

ジョブ変数

YAML を使っている場合、ジョブに対して変数を指定できます。これらの変数は、マクロ構文 $(variableName) を使ってタスク入力に渡すことや、スクリプト内でステージ変数を使ってアクセスすることができます。

YAML
クラシック

ジョブで変数を定義し、タスク内で使う例を次に示します。

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"

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

ワークスペース

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

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

YAML
クラシック

$(Build.ArtifactStagingDirectory) と $(Common.TestResultsDirectory) は、毎回のビルド前に常に削除され、再作成されます。

セルフホステッドエージェント上でパイプラインを実行する場合、既定で、$(Build.ArtifactStagingDirectory) と $(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 ディレクトリ全体を削除します。

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

注意

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

ワークスペースのクリーンに加えて、パイプライン設定 UI で [クリーン] 設定を構成することでクリーンを構成することもできます。 [クリーン] 設定が true (既定値) の場合、パイプラインのチェックアウトステップごとに clean: true を指定することと同じです。 clean: true を指定した場合は、git フェッチの前に git clean -ffdx、git reset --hard HEAD の順に実行します。 [クリーン] 設定を構成するには:

パイプラインを編集し、[...] を選び、[トリガー] を選びます。
[YAML]、[ソースの取得] を選び、任意の [クリーン] 設定を構成します。既定値は trueです。

セルフホステッドエージェント上でパイプラインを実行する場合、既定で、2 つの連続した実行の間にクリーンされるサブディレクトリはありません。その結果、それを行うタスクが実装されていれば、増分ビルドと配置を行うことができます。ただし、Get sources タスクの Clean build オプションを使って、この動作をオーバーライドできます。オプションは、使うリポジトリの種類によって異なります。

成果物のダウンロード

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

YAML
クラシック

# 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: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

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

OAuth トークンにアクセスする

ジョブ内で実行されるスクリプトが、現在の Azure Pipelines または TFS OAuth セキュリティトークンにアクセスできるようにすることができます。このトークンは、Azure Pipelines REST API に対する認証に使用できます。

YAML
クラシック

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)

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

1 つのジョブを定義する

ジョブの種類

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

サーバージョブ

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

依存関係

条件

Timeouts

複数ジョブの構成

スライス

ジョブ変数

ワークスペース

成果物のダウンロード

OAuth トークンにアクセスする

次の内容

フィードバック

フィードバック

その他のリソース

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

1 つのジョブを定義する

ジョブの種類

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

サーバー ジョブ

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

依存関係

条件

Timeouts

複数ジョブの構成

スライス

ジョブ変数

ワークスペース

成果物のダウンロード

OAuth トークンにアクセスする

次の内容

フィードバック

フィードバック

その他のリソース

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

サーバージョブ

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