定義済み変数の使用

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

変数を使うと、パイプラインのさまざまな部分に重要なデータを簡単に取り込むことができます。 これは使用できる定義済み変数の一覧です。 他にもいくつか定義済み変数がある可能性がありますが、それらは主に内部使用のための変数です。

これらの変数は、システムによって自動的に設定され、読み取り専用となります。 (例外は Build.Clean と System.Debug です)

YAML パイプラインでは、定義済みの変数を環境変数として参照できます。 たとえば、変数 Build.ArtifactStagingDirectory は変数 BUILD_ARTIFACTSTAGINGDIRECTORY になります。

クラシック パイプラインの場合、配置タスクでリリース変数を使って、共通の情報 (たとえば、環境名、リソース グループなど) を共有できます。

変数の使用に関する詳細については、こちらを参照してください。

ヒント

変数 ヘルプについては、Copilot に問い合わせてください。 詳細については、「変数値に基づいて条件を持つステージを生成するように Copilot に依頼するを参照してください。

Build.Clean

これは、ビルド エージェントがソースをクリーンアップする方法を変更する非推奨の変数です。 ソースをクリーンアップする方法については、「エージェントのローカル リポジトリをクリーンする」を参照してください。

System.AccessToken

System.AccessToken は、実行中のビルドで使われるセキュリティ トークンを保持する特別な変数です。

YAML

YAML では、変数を使って、明示的に System.AccessToken をパイプラインにマップする必要があります。 これは、ステップ レベルまたはタスク レベルで行うことができます。 たとえば、System.AccessToken を使用してコンテナー レジストリで認証できます。

steps:
- task: Docker@2
  inputs:
    command: login
    containerRegistry: '<docker connection>'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

System.AccessTokenを使って、 の既定のスコープを構成できます。

クラシック

ジョブ レベルでスクリプトとタスクが System.AccessToken にアクセスすることを許可できます。

1. ジョブに移動します

2. [その他のオプション] で、[スクリプトが OAuth トークンにアクセスできるようにする] ボックスをオンにします。

このボックスをオンにすると、スクリプトでプッシュとプルを実行できるように、資格情報セットが Git に残ります。

System.Debug

パイプラインの問題をデバッグするための詳細なログを取得するには、System.Debug を定義し、true に設定します。

1. パイプラインを編集します。

2. [変数] を選択します。

3. 名前が System.Debug、値が true の新しい変数を追加します。

   

4. 新しい変数を保存します。

System.Debug を true に設定すると、すべての実行の詳細ログが構成されます。 また、[システムの診断を有効にする] チェックボックスを使って、1 つの実行に対して詳細ログを構成することもできます。

また、パイプラインやテンプレートの変数として System.Debug を true に設定することもできます。

variables:
  system.debug: 'true'

System.Debug を true に設定すると、Agent.Diagnostic という名前の追加の変数が true に設定されます。 Agent.Diagnostic が true の場合、エージェントは、セルフホステッド エージェントのネットワークの問題のトラブルシューティングに使用できるログをさらに収集します。 詳細については、「セルフホステッド エージェントのネットワーク診断」を参照してください。

Note

Agent.Diagnostic 変数は、Agent v2.200.0 以降で使用できます。

詳細については、「ログを確認してパイプラインの問題を診断する」を参照してください。

エージェント変数 (DevOps Services)

Note

エージェント変数は、スクリプトの環境変数として、ビルド タスクではパラメーターとして使用できます。 これらを使用してビルド番号をカスタマイズしたり、バージョン コントロールのラベルやタグを適用したりすることはできません。

変数	説明
Agent.BuildDirectory	指定されたビルド パイプラインのすべてのフォルダーが作成される、エージェントのローカル パス。 この変数の値は Pipeline.Workspace と同じです。 (例: /home/vsts/work/1)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。
Agent.ContainerMapping	YAML のコンテナー リソース名から実行時の Docker ID へのマッピング。 例は表の後にあります。
Agent.HomeDirectory	エージェントがインストールされるディレクトリ。 この変数には、エージェント ソフトウェアが含まれています。 (例: c:\agent)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。
Agent.Id	エージェントの ID。
Agent.JobName	実行中のジョブの名前。 この名前は通常 Jobです。または __defaultが、マルチ構成シナリオでは構成です。
Agent.JobStatus	ビルドの状態。 Canceled Failed Succeeded SucceededWithIssues (部分的に成功) Skipped (最後のジョブ) 環境変数は AGENT_JOBSTATUS として参照する必要があります。 下位互換性のため、以前の agent.jobstatus が使用できます。
Agent.MachineName	エージェントがインストールされているマシンの名前。
Agent.Name	プールに登録されているエージェントの名前。 セルフホステッド エージェントを使用している場合は、名前を指定します。 エージェントに関するページを参照してください。
Agent.OS	エージェント ホストのオペレーティング システム。 有効な値は次のとおりです。 Windows_NT Darwin Linux コンテナーで実行している場合、エージェント ホストとコンテナーは異なるオペレーティング システムを実行できます。
Agent.OSArchitecture	エージェント ホストのオペレーティング システム プロセッサ アーキテクチャ。 有効な値は次のとおりです。 X86 X64 ARM
Agent.TempDirectory	各パイプライン ジョブの後にクリーンされる一時的なフォルダー。 このディレクトリは、公開前のテスト結果などの一時的な項目を保持するために、.NET Core CLI タスクなどのタスクで使われます。 例: Ubuntu の場合 /home/vsts/work/_temp。
Agent.ToolsDirectory	Node Tool インストーラーや Python バージョンの使用などのタスクで、ツールの複数のバージョンを切り替えるために使われるディレクトリ。 これらのタスクは、このディレクトリからツールを PATH に追加して、後続のビルド手順で使用できるようにします。 セルフホステッド エージェントで、このディレクトリを管理する詳細について参照してください。
Agent.WorkFolder	このエージェントの作業ディレクトリ。 (例: c:\agent_work)。 注: このディレクトリは、パイプライン タスクによって書き込み可能であるとは限りません (たとえば、コンテナーにマップされている場合)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。

Agent.ContainerMapping の例

{
  "one_container": {
    "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190"
  },
  "another_container": {
    "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb"
  }
}

ビルド変数 (DevOps Services)

テンプレートで使用可能とマークされていない変数をテンプレートで使用すると、変数はレンダリングされません。 変数は、テンプレートのスコープ内で値にアクセスできないため、レンダリングされません。

変数	説明	テンプレートで使用可能か?
Build.ArtifactStagingDirectory	宛先にプッシュされる前に成果物がコピーされる、エージェントのローカル パス。 (例: c:\agent_work\1\a)。 このフォルダーの一般的な用途は、ファイルのコピーとビルド成果物の発行タスクでビルド成果物を発行することです。 注: Build.ArtifactStagingDirectory と Build.StagingDirectory は交換可能です。 このディレクトリは新しいビルドの前に消去されるので、自分でクリーンする必要はありません。 Azure Pipelines の成果物に関するページを参照してください。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.BuildId	完了したビルドのレコードの ID。	No
Build.BuildNumber	完了したビルドの名前で、実行番号とも呼ばれます。 この値には何を含めるかを指定できます。 この変数の一般的な用途は、リポジトリ タブで指定するラベルの形式の一部にすることです。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.BuildUri	ビルドの URI。 (例: vstfs:///Build/Build/1430)。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.BinariesDirectory	コンパイルされたバイナリの出力フォルダーとして使用できる、エージェントのローカル パス。 セルフホステッド エージェントでは、既定では、このディレクトリをクリーンアップするように新しいビルド パイプラインが設定されていません。 [リポジトリ] タブで、このディレクトリをクリーンするようにビルドを定義できます。 (例: c:\agent_work\1\b)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.ContainerId	成果物のコンテナーの ID。 パイプラインで成果物をアップロードすると、その特定の成果物に固有のコンテナーに対して追加されます。	No
Build.CronSchedule.DisplayName	パイプライン実行をトリガーした cron スケジュールの displayName。 この変数は、YAML スケジュールされたトリガーがパイプラインの実行をトリガーする場合にのみ設定されます。 詳細については、「schedules.cron definition - Build.CronSchedule.DisplayName 変数」を参照してください	はい
Build.DefinitionName	ビルド パイプラインの名前。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.DefinitionVersion	ビルド パイプラインのバージョン。	はい
Build.QueuedBy	ID 変数の設定方法 を参照してください。. 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.QueuedById	ID 変数の設定方法 を参照してください。.	はい
Build.Reason	ビルドの実行の原因となったイベント。 Manual: ユーザーが手動でビルドをキューに入れた。 IndividualCI: 継続的インテグレーション (CI)、Git プッシュまたは Team Foundation バージョン管理 (TFVC) チェックインによってトリガーされます。 BatchedCI: Git プッシュや TFVC チェックインによる継続的インテグレーション (CI) でトリガーされ、バッチ変更が選ばれた。 Schedule: スケジュール済みのトリガー。 ValidateShelveset: ユーザーが手動で特定の TFVC シェルブセットのビルドをキューに入れた。 CheckInShelveset: ゲート チェックインのトリガー。 PullRequest: ビルドを必要とする Git ブランチ ポリシーによってビルドがトリガーされます。 BuildCompletion: ビルド 別のビルド トリガーを します。 ResourceTrigger: リソース トリガー するか、ビルド 別のビルド トリガーを します。 ビルド パイプライン トリガー、ブランチ ポリシーでのコード品質の向上に関するページを参照してください。	はい
Build.Repository.Clean	ソース リポジトリの設定で クリーン に選択した値。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.LocalPath	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 (例: c:\agent_work\1\s)。 セルフホステッド エージェントでは、新しいビルド パイプラインによって既定で変更されたファイルのみが更新されます。 [リポジトリ] タブでファイルのダウンロード方法を変更できます。 重要な注意事項: 1 つの Git リポジトリのみをチェックアウトした場合、このパスはコードへの正確なパスとなります。 複数のリポジトリをチェックアウトした場合、動作は次のようになります (Build.SourcesDirectory 変数の値とは異なる場合があります)。 セルフ (プライマリ) リポジトリのチェックアウト ステップにカスタム チェックアウト パスが定義されていない場合、またはチェックアウト パスがセルフ リポジトリのマルチ チェックアウトにおける既定のパス $(Pipeline.Workspace)/s/&<RepoName> の場合、この変数の値は既定値である $(Pipeline.Workspace)/s に戻されます。 セルフ (プライマリ) リポジトリのチェックアウト ステップに、マルチチェックアウトの既定のパスではないカスタム チェックアウト パスが定義されている場合、この変数にはセルフ リポジトリへの正確なパスが含まれます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.ID	リポジトリの一意識別子。 リポジトリの名前が変更された場合でも、この値は変更されません。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Name	トリガーするリポジトリの名前。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Provider	トリガーするリポジトリの種類。 TfsGit: TFS Git リポジトリ TfsVersionControl: Team Foundation バージョン管理 Git: 外部サーバーでホストされている Git リポジトリ GitHub Svn: Subversion この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Tfvc.Workspace	リポジトリが Team Foundation バージョン管理の場合に定義されます。 ビルド エージェントが使う TFVC ワークスペースの名前です。 たとえば、Agent.BuildDirectory が c:\agent_work\12 で Agent.Id が 8 の場合、ワークスペース名は次のようになります: ws_12_8 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Uri	トリガーするリポジトリの URL。 次に例を示します。 Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.RequestedFor	ID 変数の設定方法 を参照してください。. 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.RequestedForEmail	ID 変数の設定方法 を参照してください。.	はい
Build.RequestedForId	ID 変数の設定方法 を参照してください。.	はい
Build.SourceBranch	ビルドがキューに入れられた、トリガーするリポジトリのブランチ。 次に例をいくつか示します。 Git リポジトリのブランチ: refs/heads/main Git リポジトリの pull request: refs/pull/1/merge TFVC リポジトリのブランチ: $/teamproject/main TFVC リポジトリのゲート チェックイン: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC リポジトリのシェルブセットのビルド: myshelveset;username@live.com タグによってパイプラインがトリガーされたとき: refs/tags/your-tag-name この変数をビルド番号の形式で使う場合、スラッシュ文字 (/) はアンダースコア文字 (_) に置き換えられます。 注: TFVC では、ゲート チェックイン ビルドを実行している場合、またはシェルブセットを手動でビルドしている場合は、ビルド番号の形式でこの変数を使うことはできません。	はい
Build.SourceBranchName	ビルドがキューに入れられた、トリガーするリポジトリにあるブランチの名前。 Git リポジトリのブランチ、pull request、またはタグ: ref の最後のパスのセグメント。たとえば、refs/heads/main の場合、この値は main です。 refs/heads/feature/toolsでは、この値は toolsです。 refs/tags/your-tag-nameでは、値は your_tag_nameで、ハイフン (-) はアンダースコア (_) に置き換えられます。 TFVC リポジトリのブランチ: ワークスペースのルート サーバー パスでの最後のパスのセグメント。 たとえば、$/teamproject/main の場合、この値は main です。 TFVC リポジトリのゲート チェックインまたはシェルブセット ビルドは、シェルブセットの名前です。 たとえば、Gated_2016-06-06_05.20.51.4369;username@live.com または myshelveset;username@live.com です。 注: TFVC では、ゲート チェックイン ビルドを実行している場合、またはシェルブセットを手動でビルドしている場合は、ビルド番号の形式でこの変数を使うことはできません。	はい
Build.SourcesDirectory	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 (例: c:\agent_work\1\s)。 セルフホステッド エージェントでは、新しいビルド パイプラインによって、変更されたファイルのみが更新されます。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。 重要な注意事項: 1 つの Git リポジトリのみをチェックアウトした場合、このパスはコードへの正確なパスとなります。 複数のリポジトリをチェックアウトする場合、セルフ (プライマリ) リポジトリがマルチ チェックアウトにおける既定のパス $(Pipeline.Workspace)/s とは異なるカスタム パスにチェックアウトされても、既定値である $(Pipeline.Workspace)/s/<RepoName> に戻されます (この点で、この変数は Build.Repository.LocalPath 変数の動作とは異なります)。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.SourceVersion	このビルドに含まれる、トリガーするリポジトリの最新のバージョン コントロールの変更。 Git: コミット ID。 TFVC: 変更セット。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	はい
Build.SourceVersionMessage	トリガーするリポジトリのコミットまたは変更セットのコメント。 メッセージは、最初の行か 200 文字のどちらか短い方に切り捨てられます。 Build.SourceVersionMessage は Build.SourceVersion のコミット時のメッセージに対応します。 PR ビルドの Build.SourceVersion のコミットはマージ コミットです (ソース ブランチ上のコミットではありません)。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 また、この変数はステップ レベルでのみ使用でき、ジョブ レベルまたはステージ レベルでは使用できません。 つまり、ジョブが開始され、コードがチェックアウトされるまで、メッセージは抽出されません。 注: Build.SourceVersionMessage 変数は、ビルドが有効になっている間に Batch が変更 場合、Bitbucket リポジトリのクラシック ビルド パイプラインでは機能しません。	No
Build.StagingDirectory	宛先にプッシュされる前に成果物がコピーされる、エージェントのローカル パス。 (例: c:\agent_work\1\a)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。 このフォルダーの一般的な用途は、ファイルのコピーとビルド成果物の発行タスクでビルド成果物を発行することです。 注: Build.ArtifactStagingDirectory と Build.StagingDirectory は交換可能です。 このディレクトリは新しいビルドの前に消去されるので、自分でクリーンする必要はありません。 Azure Pipelines の成果物に関するページを参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Git.SubmoduleCheckout	チェックアウト サブモジュールに対して選択した値は、[リポジトリ] タブ。複数のリポジトリがチェックアウトされた場合、この値はトリガーリポジトリの設定を追跡します。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No
Build.SourceTfvcShelveset	リポジトリが Team Foundation バージョン管理の場合に定義されます。 ゲートビルド または シェルブセットビルドを実行している場合、この変数はビルド シェルブセットの名前に設定されます。 注: この変数は、ビルド番号の形式でのビルド用途には無効な値が生成されます。	No
Build.TriggeredBy.BuildId	ビルド 別のビルド トリガー 場合、この変数はトリガーするビルドの BuildID に設定されます。 クラシック パイプラインでは、ビルド完了トリガーによってこの変数がトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.DefinitionId	ビルド 別のビルド トリガー 場合、この変数はトリガーするビルドの DefinitionID に設定されます。 クラシック パイプラインでは、ビルド完了トリガーによってこの変数がトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.DefinitionName	ビルド 別のビルド トリガー 場合、この変数はトリガーするビルド パイプラインの名前に設定されます。 クラシック パイプラインでは、ビルド完了トリガーによってこの変数がトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.BuildNumber	ビルド 別のビルド トリガー 場合、この変数はトリガーするビルドの数に設定されます。 クラシック パイプラインでは、ビルド完了トリガーによってこの変数がトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.ProjectID	ビルド 別のビルド トリガー 場合、この変数はトリガーするビルドを含むプロジェクトの ID に設定されます。 クラシック パイプラインでは、ビルド完了トリガーによってこの変数がトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Common.TestResultsDirectory	テスト結果が作成される、エージェントのローカル パス。 (例: c:\agent_work\1\TestResults)。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No

パイプライン変数

変数	説明
Pipeline.Workspace	特定のパイプラインのワークスペース ディレクトリ。 この変数の値は Agent.BuildDirectory と同じです。 たとえば、/home/vsts/work/1 となります。 エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造 参照してください。

ヒント

クラシック リリース パイプラインを使用している場合は、クラシック リリースとアーティファクト変数 使用して、パイプライン全体でデータを格納およびアクセスできます。

デプロイ ジョブ変数

これらの変数は、特定の デプロイ ジョブ にスコープが設定され、ジョブの実行時にのみ解決されます。

変数	説明
Environment.Name	配置ジョブで、配置手順を実行し配置履歴を記録する対象となる環境の名前。 たとえば、smarthotel-dev となります。
Environment.Id	配置ジョブの対象となる環境の ID。 たとえば、10 となります。
Environment.ResourceName	配置ジョブで、配置手順を実行し配置履歴を記録する対象となる環境内の特定のリソースの名前。 たとえば、bookings 環境 smarthotel-devにリソースとして追加される Kubernetes 名前空間です。
Environment.ResourceId	配置ジョブで、配置手順を実行する対象となる環境内の特定のリソースの ID。 たとえば、4 となります。
Strategy.Name	配置戦略の名前: canary、runOnce、または rolling。
Strategy.CycleName	配置における現在のサイクル名。 オプションは、PreIteration、Iteration、または PostIteration です。

システム変数

テンプレートで使用可能とマークされていない変数をテンプレートで使用すると、変数はレンダリングされません。 変数は、テンプレートのスコープ内で値にアクセスできないため、レンダリングされません。

変数	説明	テンプレートで使用可能か?
System.AccessToken	OAuth トークンを使った REST API へのアクセス。 YAML スクリプトからの System.AccessToken の使用。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	はい
System.CollectionId	Azure DevOps 組織またはコレクションの GUID。	はい
System.CollectionUri	Azure DevOps 組織またはコレクションの URI。 (例: https://dev.azure.com/fabrikamfiber/)。	はい
System.DefaultWorkingDirectory	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 例: c:\agent_work\1\s エージェント・ディレクトリー構造の詳細については、エージェント・ディレクトリー構造を参照してください。 セルフホステッド エージェントでは、新しいビルド パイプラインによって既定で変更されたファイルのみが更新されます。 [リポジトリ] タブでファイルのダウンロード方法を変更できます。 この変数はエージェント スコープです。 スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	はい
System.DefinitionId	ビルド パイプラインの ID。	はい
System.HostType	パイプラインがビルドの場合は build に設定されます。 リリースの場合、値は、配置グループ ジョブでは deployment、ゲートの評価中は gates、その他の (エージェントおよびエージェントレス) ジョブのときは release になります。	はい
System.JobAttempt	このジョブが最初に試行されたときに 1 が設定され、ジョブが再試行されるたびにインクリメントされます。	No
System.JobDisplayName	ジョブに付けられた人間が判読できる名前。	No
System.JobId	1 つのジョブの 1 回の試行に対する一意識別子。 値は現在のパイプラインに特有のものです。	No
System.JobName	ジョブの名前。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.OidcRequestUri	OpenID Connect (OIDC) を使用する Entra ID による認証用の idToken を生成します。 詳細情報。	はい
System.PhaseAttempt	このフェーズが最初に試行されたときに 1 が設定され、ジョブが再試行されるたびにインクリメントされます。 注: "フェーズ" は、ジョブのデザイン時を表す、ほぼ冗長な概念です (一方、ジョブは、フェーズの実行時バージョンです)。 フェーズ の概念は、主に Azure Pipelines から削除されます。 マトリックス ジョブとマルチ構成ジョブは、フェーズがジョブとは異なる唯一の場所です。 1 つのフェーズで、入力のみが異なる複数のジョブのインスタンスを作成できます。	No
System.PhaseDisplayName	フェーズに付けられた人間が判読できる名前。	No
System.PhaseName	ジョブの文字列ベースの識別子。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.PlanId	1 つのパイプライン実行に対する文字列ベースの識別子。	No
System.PullRequest.IsFork	pull request がリポジトリのフォークからの場合、この変数には True が設定されます。 それ以外の場合は、False に設定されます。	はい
System.PullRequest.PullRequestId	このビルドの原因となった pull request の ID。 (例: 17)。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。	No
System.PullRequest.PullRequestNumber	このビルドの原因となった pull request の番号。 この変数は、異なる pull request ID と pull request 番号を持つ GitHub からの pull request に対して設定されます。 この変数は、ブランチ ポリシーが PR に影響を与える場合にのみ、YAML パイプラインで使用できます。	No
System.PullRequest.targetBranchName	pull request のターゲット ブランチの名前。 この変数は、パイプラインで使用して、pull request のターゲット ブランチに基づいてタスクやステップを条件付きで実行できます。 たとえば、変更がマージされるブランチに応じて、異なるテスト セットやコード分析ツールをトリガーすることができます。	No
System.PullRequest.SourceBranch	pull request でレビューされているブランチ。 たとえば、Azure Repos での refs/heads/users/raisa/new-feature。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。 この変数は、ブランチ ポリシーが PR に影響を与える場合にのみ、YAML パイプラインで使用できます。	No
System.PullRequest.SourceCommitId	pull request でレビューされているコミット。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。 この変数は、ブランチ ポリシーが PR に影響を与える場合にのみ、YAML パイプラインで使用できます。
System.PullRequest.SourceRepositoryURI	pull request を含むリポジトリへの URL。 (例: https://dev.azure.com/ouraccount/_git/OurProject)。	No
System.PullRequest.TargetBranch	pull request のターゲットとなるブランチ。 たとえば、リポジトリが Azure Repos にある場合 refs/heads/main、リポジトリが GitHub にある場合 main。 この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます。 この変数は、ブランチ ポリシーが PR に影響を与える場合にのみ、YAML パイプラインで使用できます。	No
System.StageAttempt	このステージが最初に試行されたときに 1 が設定され、ステージが再試行されるたびにインクリメントされます。	No
System.StageDisplayName	ステージに付けられた人間が判読できる名前。	No
System.StageName	ステージの文字列ベースの識別子。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.TeamFoundationCollectionUri	Azure DevOps 組織またはコレクションの URI。 (例: https://dev.azure.com/fabrikamfiber/)。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	はい
System.TeamProject	このビルドを含むプロジェクトの名前。	はい
System.TeamProjectId	このビルドが属するプロジェクトの ID。	はい
System.TimelineId	1 つのパイプライン実行の詳細とログのための文字列ベースの識別子。	No
TF_BUILD	ビルド タスクでスクリプトが実行される場合は、True に設定します。 この変数はエージェント スコープであり、スクリプトの環境変数として、およびビルド タスクのパラメーターとして使用できます。 ビルド番号の一部として、またはバージョン コントロール タグとして使用することはできません。	No

チェック変数 (DevOps Services)

変数	説明
Checks.StageAttempt	このステージが最初に試行されたときに 1 が設定され、ステージが再試行されるたびにインクリメントされます。 この変数は、環境に対する承認またはチェック内でのみ使用できます。 たとえば、$(Checks.StageAttempt) は REST API の呼び出しチェックの中で使用できます。

ID 変数はどのように設定されますか?

値はビルドの原因によって異なり、Azure Repos リポジトリに固有のものです。

ビルドがトリガーされた原因	Build.QueuedBy と Build.QueuedById の値が基づくもの	Build.RequestedFor と Build.RequestedForId の値が基づくもの
Git で、または継続的インテグレーション (CI) のトリガーによる場合	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	変更をプッシュまたはチェックインしたユーザー。
Git で、ブランチ ポリシー ビルドによる場合。	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	変更をチェックインしたユーザー。
TFVC で、ゲート チェックイン トリガーによる場合	変更をチェックインしたユーザー。	変更をチェックインしたユーザー。
Git または TFVC で、スケジュールされたトリガーによる場合	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	システム ID。例: [DefaultCollection]\Project Collection Service Accounts
[ビルドをキューに挿入] ボタンをクリックしたため	自分	自分

変数値に基づいて条件を持つステージを生成するように Copilot に依頼する

Copilot 使用して、変数の値によって決定される条件を持つステージを生成します。

このプロンプト例では、前のステージが正常に実行されたことを示 Agent.JobStatus 実行するステージを定義します。

Agent.JobStatus が Succeeded または SucceededWithIssues場合にのみ実行される新しい Azure DevOps ステージを作成します。

要件を満たす値を使用するようにプロンプトをカスタマイズできます。 たとえば、パイプラインが失敗した場合にのみ実行されるステージの作成に関するヘルプを求めることができます。

Note

GitHub Copilot は AI を利用しているため、驚きや間違いが起こりうる可能性があります。 生成されたコードまたは提案を必ず確認してください。 GitHub Copilot の一般的な使用、製品への影響、人による監視、プライバシーの詳細については、GitHub Copilot に関する FAQ参照してください。