Use predefined variables

Article
12/12/2024

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

Variables give you a convenient way to get key bits of data into various parts of your pipeline. This is a list of predefined variables that are available for your use. There may be a few other predefined variables, but they're mostly for internal use.

These variables are automatically set by the system and read-only. (The exceptions are Build.Clean and System.Debug.)

In YAML pipelines, you can reference predefined variables as environment variables. For example, the variable Build.ArtifactStagingDirectory becomes the variable BUILD_ARTIFACTSTAGINGDIRECTORY.

For classic pipelines, you can use release variables in your deploy tasks to share the common information (for example, Environment Name, Resource Group, etc.).

Learn more about working with variables.

Tip

You can ask Copilot for help with variables. To learn more, see Ask Copilot to generate a stage with a condition based on variable values.

Build.Clean

This is a deprecated variable that modifies how the build agent cleans up source. To learn how to clean up source, see Clean the local repo on the agent.

System.AccessToken

System.AccessToken is a special variable that carries the security token used by the running build.

YAML
Classic

In YAML, you must explicitly map System.AccessToken into the pipeline using a variable. You can do this at the step or task level. For example, you can use System.AccessToken to authenticate with a container registry.

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

You can configure the default scope for System.AccessToken using build job authorization scope.

System.Debug

For more detailed logs to debug pipeline problems, define System.Debug and set it to true.

Edit your pipeline.
Select Variables.
Add a new variable with the name System.Debug and value true.
Save the new variable.

Setting System.Debug to true configures verbose logs for all runs. You can also configure verbose logs for a single run with the Enable system diagnostics checkbox.

You can also set System.Debug to true as a variable in a pipeline or template.

variables:
  system.debug: 'true'

When System.Debug is set to true, an extra variable named Agent.Diagnostic is set to true. When Agent.Diagnostic is true, the agent collects more logs that can be used for troubleshooting network issues for self-hosted agents. For more information, see Network diagnostics for self-hosted agents.

Note

The Agent.Diagnostic variable is available with Agent v2.200.0 and higher.

For more information, see Review logs to diagnose pipeline issues.

Agent variables (DevOps Services)

Note

You can use agent variables as environment variables in your scripts and as parameters in your build tasks. You cannot use them to customize the build number or to apply a version control label or tag.

Variable	Description
Agent.BuildDirectory	The local path on the agent where all folders for a given build pipeline are created. This variable has the same value as `Pipeline.Workspace`. For example: `/home/vsts/work/1`.
Agent.ContainerMapping	A mapping from container resource names in YAML to their Docker IDs at runtime. Example follows table.
Agent.HomeDirectory	The directory the agent is installed into. This contains the agent software. For example: `c:\agent`.
Agent.Id	The ID of the agent.
Agent.JobName	The name of the running job. This will usually be "Job"; or "__default", but in multi-config scenarios, will be the configuration.
Agent.JobStatus	The status of the build. `Canceled` `Failed` `Succeeded` `SucceededWithIssues` (partially successful) `Skipped` (last job) The environment variable should be referenced as `AGENT_JOBSTATUS`. The older `agent.jobstatus` is available for backwards compatibility.
Agent.MachineName	The name of the machine on which the agent is installed.
Agent.Name	The name of the agent that is registered with the pool. If you're using a self-hosted agent, then this name is specified by you. See agents.
Agent.OS	The operating system of the agent host. Valid values are: `Windows_NT` `Darwin` `Linux` If you're running in a container, the agent host and container may be running different operating systems.
Agent.OSArchitecture	The operating system processor architecture of the agent host. Valid values are: `X86` `X64` `ARM`
Agent.TempDirectory	A temporary folder that is cleaned after each pipeline job. This directory is used by tasks such as .NET Core CLI task to hold temporary items like test results before they're published. For example: `/home/vsts/work/_temp` for Ubuntu.
Agent.ToolsDirectory	The directory used by tasks such as Node Tool Installer and Use Python Version to switch between multiple versions of a tool. These tasks add tools from this directory to `PATH` so that subsequent build steps can use them. Learn about managing this directory on a self-hosted agent.
Agent.WorkFolder	The working directory for this agent. For example: `c:\agent_work`. Note: This directory isn't guaranteed to be writable by pipeline tasks (for example, when mapped into a container)

Example of Agent.ContainerMapping:

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

Build variables (DevOps Services)

When you use a variable in a template that is not marked as available in templates, the variable will not render. The variable won't render because its value is not accessible within the template's scope.

Variable	Description	Available in templates?
Build.ArtifactStagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildId	The ID of the record for the completed build.	No
Build.BuildNumber	The name of the completed build, also known as the run number. You can specify what is included in this value. A typical use of this variable is to make it part of the label format, which you specify on the repository tab. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildUri	The URI for the build. For example: `vstfs:///Build/Build/1430`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BinariesDirectory	The local path on the agent you can use as an output folder for compiled binaries. By default, new build pipelines aren't set up to clean this directory. You can define your build to clean it up on the Repository tab. For example: `c:\agent_work\1\b`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.ContainerId	The ID of the container for your artifact. When you upload an artifact in your pipeline, it's added to a container that is specific for that particular artifact.	No
Build.CronSchedule.DisplayName	The `displayName` of the cron schedule that triggered the pipeline run. This variable is only set if the pipeline run is triggered by a YAML scheduled trigger. For more information, see schedules.cron definition - Build.CronSchedule.DisplayName variable	Yes
Build.DefinitionName	The name of the build pipeline. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.DefinitionVersion	The version of the build pipeline.	Yes
Build.QueuedBy	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.QueuedById	See "How are the identity variables set?".	Yes
Build.Reason	The event that caused the build to run. `Manual`: A user manually queued the build. `IndividualCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in. `BatchedCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected. `Schedule`: Scheduled trigger. `ValidateShelveset`: A user manually queued the build of a specific TFVC shelveset. `CheckInShelveset`: Gated check-in trigger. `PullRequest`: The build was triggered by a Git branch policy that requires a build. `BuildCompletion`: The build was triggered by another build `ResourceTrigger`: The build was triggered by a resource trigger or it was triggered by another build. See Build pipeline triggers, Improve code quality with branch policies.	Yes
Build.Repository.Clean	The value you've selected for Clean in the source repository settings. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.LocalPath	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. Important note: If you check out only one Git repository, this path is the exact path to the code. If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable): If the checkout step for the self (primary) repository has no custom checkout path defined, or the checkout path is the multi-checkout default path `$(Pipeline.Workspace)/s/&<RepoName>` for the self repository, the value of this variable reverts to its default value, which is `$(Pipeline.Workspace)/s`. If the checkout step for the self (primary) repository does have a custom checkout path defined (and it's not its multi-checkout default path), this variable contains the exact path to the self repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.ID	The unique identifier of the repository. This won't change, even if the name of the repository does. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Name	The name of the triggering repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Provider	The type of the triggering repository. `TfsGit`: TFS Git repository `TfsVersionControl`: Team Foundation Version Control `Git`: Git repository hosted on an external server `GitHub` `Svn`: Subversion This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Tfvc.Workspace	Defined if your repository is Team Foundation Version Control. The name of the TFVC workspace used by the build agent. For example, if the Agent.BuildDirectory is `c:\agent_work\12` and the Agent.Id is `8`, the workspace name could be: `ws_12_8` This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Uri	The URL for the triggering repository. For example: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.RequestedFor	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.RequestedForEmail	See "How are the identity variables set?".	Yes
Build.RequestedForId	See "How are the identity variables set?".	Yes
Build.SourceBranch	The branch of the triggering repo the build was queued for. Some examples: Git repo branch: `refs/heads/main` Git repo pull request: `refs/pull/1/merge` TFVC repo branch: `$/teamproject/main` TFVC repo gated check-in: `Gated_2016-06-06_05.20.51.4369;username@live.com` TFVC repo shelveset build: `myshelveset;username@live.com` When your pipeline is triggered by a tag: `refs/tags/your-tag-name` When you use this variable in your build number format, the forward slash characters (`/`) are replaced with underscore characters `_`). Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.	Yes
Build.SourceBranchName	The name of the branch in the triggering repo the build was queued for. Git repo branch, pull request, or tag: The last path segment in the ref. For example, in `refs/heads/main` this value is `main`. In `refs/heads/feature/tools` this value is `tools`. In `refs/tags/your-tag-name` this value is `your-tag-name`. TFVC repo branch: The last path segment in the root server path for the workspace. For example, in `$/teamproject/main` this value is `main`. TFVC repo gated check-in or shelveset build is the name of the shelveset. For example, `Gated_2016-06-06_05.20.51.4369;username@live.com` or `myshelveset;username@live.com`. Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.	Yes
Build.SourcesDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. Important note: If you check out only one Git repository, this path is the exact path to the code. If you check out multiple repositories, it reverts to its default value, which is `$(Pipeline.Workspace)/s`, even if the self (primary) repository is checked out to a custom path different from its multi-checkout default path `$(Pipeline.Workspace)/s/<RepoName>` (in this respect, the variable differs from the behavior of the Build.Repository.LocalPath variable). This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceVersion	The latest version control change of the triggering repo that is included in this build. Git: The commit ID. TFVC: the changeset. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
Build.SourceVersionMessage	The comment of the commit or changeset for the triggering repo. We truncate the message to the first line or 200 characters, whichever is shorter. The `Build.SourceVersionMessage` corresponds to the message on `Build.SourceVersion` commit. The `Build.SourceVersion` commit for a PR build is the merge commit (not the commit on the source branch). This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. Also, this variable is only available on the step level and is not available in the job or stage levels (that is, the message isn't extracted until the job starts and the code is checked out). Note: This variable is available in TFS 2015.4. Note: The Build.SourceVersionMessage variable does not work with classic build pipelines in Bitbucket repositories when Batch changes while a build is in progress is enabled.	No
Build.StagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Git.SubmoduleCheckout	The value you've selected for Checkout submodules on the repository tab. With multiple repos checked out, this value tracks the triggering repository's setting. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceTfvcShelveset	Defined if your repository is Team Foundation Version Control. If you're running a gated build or a shelveset build, this is set to the name of the shelveset you're building. Note: This variable yields a value that is invalid for build use in a build number format.	No
Build.TriggeredBy.BuildId	If the build was triggered by another build, then this variable is set to the BuildID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.DefinitionId	If the build was triggered by another build, then this variable is set to the DefinitionID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.DefinitionName	If the build was triggered by another build, then this variable is set to the name of the triggering build pipeline. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.BuildNumber	If the build was triggered by another build, then this variable is set to the number of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.ProjectID	If the build was triggered by another build, then this variable is set to ID of the project that contains the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Common.TestResultsDirectory	The local path on the agent where the test results are created. For example: `c:\agent_work\1\TestResults`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Pipeline variables (DevOps Services)

Variable	Description
Pipeline.Workspace	Workspace directory for a particular pipeline. This variable has the same value as `Agent.BuildDirectory`. For example, `/home/vsts/work/1`.

Tip

If you are using classic release pipelines, you can use classic releases and artifacts variables to store and access data throughout your pipeline.

Deployment job variables (DevOps Services)

These variables are scoped to a specific Deployment job and will be resolved only at job execution time.

Variable	Description
Environment.Name	Name of the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `smarthotel-dev`.
Environment.Id	ID of the environment targeted in the deployment job. For example, `10`.
Environment.ResourceName	Name of the specific resource within the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `bookings` which is a Kubernetes namespace that has been added as a resource to the environment `smarthotel-dev`.
Environment.ResourceId	ID of the specific resource within the environment targeted in the deployment job to run the deployment steps. For example, `4`.
Strategy.Name	The name of the deployment strategy: `canary`, `runOnce`, or `rolling`.
Strategy.CycleName	The current cycle name in a deployment. Options are `PreIteration`, `Iteration`, or `PostIteration`.

System variables (DevOps Services)

Variable	Description	Available in templates?
System.AccessToken	Use the OAuth token to access the REST API. Use System.AccessToken from YAML scripts. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.CollectionId	The GUID of the TFS collection or Azure DevOps organization.	Yes
System.CollectionUri	The URI of the TFS collection or Azure DevOps organization. For example: `https://dev.azure.com/fabrikamfiber/`.	Yes
System.DefaultWorkingDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s` By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.DefinitionId	The ID of the build pipeline.	Yes
System.HostType	Set to `build` if the pipeline is a build. For a release, the values are `deployment` for a Deployment group job, `gates` during evaluation of gates, and `release` for other (Agent and Agentless) jobs.	Yes
System.JobAttempt	Set to 1 the first time this job is attempted, and increments every time the job is retried.	No
System.JobDisplayName	The human-readable name given to a job.	No
System.JobId	A unique identifier for a single attempt of a single job. The value is unique to the current pipeline.	No
System.JobName	The name of the job, typically used for expressing dependencies and accessing output variables.	No
System.OidcRequestUri	Generate an `idToken` for authentication with Entra ID using OpenID Connect (OIDC). Learn more.	Yes
System.PhaseAttempt	Set to 1 the first time this phase is attempted, and increments every time the job is retried. Note: "Phase" is a mostly redundant concept, which represents the design-time for a job (whereas job was the runtime version of a phase). We've mostly removed the concept of "phase" from Azure Pipelines. Matrix and multi-config jobs are the only place where "phase" is still distinct from "job." One phase can instantiate multiple jobs, which differ only in their inputs.	No
System.PhaseDisplayName	The human-readable name given to a phase.	No
System.PhaseName	A string-based identifier for a job, typically used for expressing dependencies and accessing output variables.	No
System.PlanId	A string-based identifier for a single pipeline run.	No
System.PullRequest.IsFork	If the pull request is from a fork of the repository, this variable is set to `True`. Otherwise, it's set to `False`.	Yes
System.PullRequest.PullRequestId	The ID of the pull request that caused this build. For example: `17`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy).	No
System.PullRequest.PullRequestNumber	The number of the pull request that caused this build. This variable is populated for pull requests from GitHub that have a different pull request ID and pull request number. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.targetBranchName	The name of the target branch for a pull request. This variable can be used in a pipeline to conditionally execute tasks or steps based on the target branch of the pull request. For example, you might want to trigger a different set of tests or code analysis tools depending on the branch that the changes are being merged into.	No
System.PullRequest.SourceBranch	The branch that is being reviewed in a pull request. For example: `refs/heads/users/raisa/new-feature` for Azure Repos. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy). This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.SourceCommitId	The commit that is being reviewed in a pull request. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy). This variable is only available in a YAML pipeline if the PR is affected by a branch policy.
System.PullRequest.SourceRepositoryURI	The URL to the repo that contains the pull request. For example: `https://dev.azure.com/ouraccount/_git/OurProject`.	No
System.PullRequest.TargetBranch	The branch that is the target of a pull request. For example: `refs/heads/main` when your repository is in Azure Repos and `main` when your repository is in GitHub. This variable is initialized only if the build ran because of a Git PR affected by a branch policy. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.StageAttempt	Set to 1 the first time this stage is attempted, and increments every time the stage is retried.	No
System.StageDisplayName	The human-readable name given to a stage.	No
System.StageName	A string-based identifier for a stage, typically used for expressing dependencies and accessing output variables.	No
System.TeamFoundationCollectionUri	The URI of the TFS collection or Azure DevOps organization. For example: `https://dev.azure.com/fabrikamfiber/`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.TeamProject	The name of the project that contains this build.	Yes
System.TeamProjectId	The ID of the project that this build belongs to.	Yes
System.TimelineId	A string-based identifier for the execution details and logs of a single pipeline run.	No
TF_BUILD	Set to `True` if the script is being run by a build task. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Checks variables (DevOps Services)

Variable	Description
Checks.StageAttempt	Set to 1 the first time this stage is attempted, and increments every time the stage is retried. This variable can only be used within an approval or check for an environment. For example, you could use `$(Checks.StageAttempt)` within an Invoke REST API check.

Agent variables (DevOps Server 2022)

Note

Variable	Description
Agent.BuildDirectory	The local path on the agent where all folders for a given build pipeline are created. This variable has the same value as `Pipeline.Workspace`. For example: `/home/vsts/work/1`.
Agent.ContainerMapping	A mapping from container resource names in YAML to their Docker IDs at runtime. Example follows table.
Agent.HomeDirectory	The directory the agent is installed into. This contains the agent software. For example: `c:\agent`.
Agent.Id	The ID of the agent.
Agent.JobName	The name of the running job. This will usually be "Job" or "__default", but in multi-config scenarios, will be the configuration.
Agent.JobStatus	The status of the build. `Canceled` `Failed` `Succeeded` `SucceededWithIssues` (partially successful) `Skipped` (last job) The environment variable should be referenced as `AGENT_JOBSTATUS`. The older `agent.jobstatus` is available for backwards compatibility.
Agent.MachineName	The name of the machine on which the agent is installed.
Agent.Name	The name of the agent that is registered with the pool. If you're using a self-hosted agent, then this name is specified by you. See agents.
Agent.OS	The operating system of the agent host. Valid values are: `Windows_NT` `Darwin` `Linux` If you're running in a container, the agent host and container might be running different operating systems.
Agent.OSArchitecture	The operating system processor architecture of the agent host. Valid values are: `X86` `X64` `ARM`
Agent.TempDirectory	A temporary folder that is cleaned after each pipeline job. This directory is used by tasks such as .NET Core CLI task to hold temporary items like test results before they're published. For example: `/home/vsts/work/_temp` for Ubuntu.
Agent.ToolsDirectory	The directory used by tasks such as Node Tool Installer and Use Python Version to switch between multiple versions of a tool. These tasks add tools from this directory to `PATH` so that subsequent build steps can use them. Learn about managing this directory on a self-hosted agent.
Agent.WorkFolder	The working directory for this agent. For example: `c:\agent_work`. Note: This directory isn't guaranteed to be writable by pipeline tasks (for example, when mapped into a container).

Example of Agent.ContainerMapping:

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

Build variables (DevOps Server 2022)

Variable	Description	Available in templates?
Build.ArtifactStagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildId	The ID of the record for the completed build.	No
Build.BuildNumber	The name of the completed build, also known as the run number. You can specify what is included in this value. A typical use of this variable is to make it part of the label format, which you specify on the repository tab. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildUri	The URI for the build. For example: `vstfs:///Build/Build/1430`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BinariesDirectory	The local path on the agent you can use as an output folder for compiled binaries. By default, new build pipelines aren't set up to clean this directory. You can define your build to clean it up on the Repository tab. For example: `c:\agent_work\1\b`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.ContainerId	The ID of the container for your artifact. When you upload an artifact in your pipeline, it's added to a container that is specific for that particular artifact.	No
Build.CronSchedule.DisplayName	The `displayName` of the cron schedule that triggered the pipeline run. This variable is only set if the pipeline run is triggered by a YAML scheduled trigger. For more information, see schedules.cron definition - Build.CronSchedule.DisplayName variable. This variable is available in Azure DevOps Server 2022.1 and higher.	Yes
Build.DefinitionName	The name of the build pipeline. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.DefinitionVersion	The version of the build pipeline.	Yes
Build.QueuedBy	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.QueuedById	See "How are the identity variables set?.	Yes
Build.Reason	The event that caused the build to run. `Manual`: A user manually queued the build. `IndividualCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in. `BatchedCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected. `Schedule`: Scheduled trigger. `ValidateShelveset`: A user manually queued the build of a specific TFVC shelveset. `CheckInShelveset`: Gated check-in trigger. `PullRequest`: The build was triggered by a Git branch policy that requires a build. `BuildCompletion`: The build was triggered by another build `ResourceTrigger`: The build was triggered by a resource trigger or it was triggered by another build. See Build pipeline triggers, Improve code quality with branch policies.	Yes
Build.Repository.Clean	The value you've selected for Clean in the source repository settings. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.LocalPath	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. Important note: If you check out only one Git repository, this path is the exact path to the code. If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable): If the checkout step for the self (primary) repository has no custom checkout path defined, or the checkout path is the multi-checkout default path `$(Pipeline.Workspace)/s/<RepoName>` for the self repository, the value of this variable reverts to its default value, which is `$(Pipeline.Workspace)/s`. If the checkout step for the self (primary) repository does have a custom checkout path defined (and it's not its multi-checkout default path), this variable contains the exact path to the self repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.ID	The unique identifier of the repository. This won't change, even if the name of the repository does. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Name	The name of the triggering repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Provider	The type of the triggering repository. `TfsGit`: TFS Git repository `TfsVersionControl`: Team Foundation Version Control `Git`: Git repository hosted on an external server `GitHub` `Svn`: Subversion This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Tfvc.Workspace	Defined if your repository is Team Foundation Version Control. The name of the TFVC workspace used by the build agent. For example, if the Agent.BuildDirectory is `c:\agent_work\12` and the Agent.Id is `8`, the workspace name could be: `ws_12_8`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Uri	The URL for the triggering repository. For example: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.RequestedFor	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.RequestedForEmail	See "How are the identity variables set?".	Yes
Build.RequestedForId	See "How are the identity variables set?".	Yes
Build.SourceBranch	The branch of the triggering repo the build was queued for. Some examples: Git repo branch: `refs/heads/main` Git repo pull request: `refs/pull/1/merge` TFVC repo branch: `$/teamproject/main` TFVC repo gated check-in: `Gated_2016-06-06_05.20.51.4369;username@live.com` TFVC repo shelveset build: `myshelveset;username@live.com` When your pipeline is triggered by a tag: `refs/tags/your-tag-name` When you use this variable in your build number format, the forward slash characters (`/`) are replaced with underscore characters `_`). Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.	Yes
Build.SourceBranchName	The name of the branch in the triggering repo the build was queued for. Git repo branch, pull request, or tag: The last path segment in the ref. For example, in `refs/heads/main` this value is `main`. In `refs/heads/feature/tools` this value is `tools`. In `refs/tags/your-tag-name` this value is `your-tag-name`. TFVC repo branch: The last path segment in the root server path for the workspace. For example, in `$/teamproject/main` this value is `main`. TFVC repo gated check-in or shelveset build is the name of the shelveset. For example, `Gated_2016-06-06_05.20.51.4369;username@live.com` or `myshelveset;username@live.com`. Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.	Yes
Build.SourcesDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. Important note: If you check out only one Git repository, this path is the exact path to the code. If you check out multiple repositories, it reverts to its default value, which is `$(Pipeline.Workspace)/s`, even if the self (primary) repository is checked out to a custom path different from its multi-checkout default path `$(Pipeline.Workspace)/s/<RepoName>` (in this respect, the variable differs from the behavior of the Build.Repository.LocalPath variable). This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceVersion	The latest version control change of the triggering repo that is included in this build. Git: The commit ID. TFVC: the changeset. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
Build.SourceVersionMessage	The comment of the commit or changeset for the triggering repo. We truncate the message to the first line or 200 characters, whichever is shorter. The `Build.SourceVersionMessage` corresponds to the message on `Build.SourceVersion` commit. The `Build.SourceVersion` commit for a PR build is the merge commit (not the commit on the source branch). This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. Also, this variable is only available on the step level and is not available in the job or stage levels (that is, the message isn't extracted until the job starts and the code is checked out). Note: This variable is available in TFS 2015.4. Note: The Build.SourceVersionMessage variable does not work with classic build pipelines in Bitbucket repositories when Batch changes while a build is in progress is enabled.	No
Build.StagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Git.SubmoduleCheckout	The value you've selected for Checkout submodules on the repository tab. With multiple repos checked out, this value tracks the triggering repository's setting. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceTfvcShelveset	Defined if your repository is Team Foundation Version Control. If you're running a gated build or a shelveset build, this is set to the name of the shelveset you're building. Note: This variable yields a value that is invalid for build use in a build number format.	No
Build.TriggeredBy.BuildId	If the build was triggered by another build, then this variable is set to the BuildID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.DefinitionId	If the build was triggered by another build, then this variable is set to the DefinitionID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.DefinitionName	If the build was triggered by another build, then this variable is set to the name of the triggering build pipeline. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.BuildNumber	If the build was triggered by another build, then this variable is set to the number of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Build.TriggeredBy.ProjectID	If the build was triggered by another build, then this variable is set to ID of the project that contains the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. If you're triggering a YAML pipeline using `resources`, you should use the resources variables instead.	No
Common.TestResultsDirectory	The local path on the agent where the test results are created. For example: `c:\agent_work\1\TestResults`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Pipeline variables (DevOps Server 2022)

Variable	Description
Pipeline.Workspace	Workspace directory for a particular pipeline. This variable has the same value as `Agent.BuildDirectory`. For example, `/home/vsts/work/1`.

Tip

If you are using classic release pipelines, you can use classic releases and artifacts variables to store and access data throughout your pipeline.

Deployment job variables (DevOps Server 2022)

These variables are scoped to a specific Deployment job and will be resolved only at job execution time.

Variable	Description
Environment.Name	Name of the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `smarthotel-dev`.
Environment.Id	ID of the environment targeted in the deployment job. For example, `10`.
Environment.ResourceName	Name of the specific resource within the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `bookings` which is a Kubernetes namespace that has been added as a resource to the environment `smarthotel-dev`.
Environment.ResourceId	ID of the specific resource within the environment targeted in the deployment job to run the deployment steps. For example, `4`.
Strategy.Name	The name of the deployment strategy: `canary`, `runOnce`, or `rolling`.
Strategy.CycleName	The current cycle name in a deployment. Options are `PreIteration`, `Iteration`, or `PostIteration`.

System variables (DevOps Server 2022)

Variable	Description	Available in templates?
System.AccessToken	Use the OAuth token to access the REST API. Use System.AccessToken from YAML scripts. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.CollectionId	The GUID of the TFS collection or Azure DevOps organization.	Yes
System.CollectionUri	The URI of the TFS collection or Azure DevOps organization. For example: `https://dev.azure.com/fabrikamfiber/`.	Yes
System.DefaultWorkingDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s` By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.DefinitionId	The ID of the build pipeline.	Yes
System.HostType	Set to `build` if the pipeline is a build. For a release, the values are `deployment` for a Deployment group job, `gates` during evaluation of gates, and `release` for other (Agent and Agentless) jobs.	Yes
System.JobAttempt	Set to 1 the first time this job is attempted, and increments every time the job is retried.	No
System.JobDisplayName	The human-readable name given to a job.	No
System.JobId	A unique identifier for a single attempt of a single job. The value is unique to the current pipeline.	No
System.JobName	The name of the job, typically used for expressing dependencies and accessing output variables.	No
System.PhaseAttempt	Set to 1 the first time this phase is attempted, and increments every time the job is retried. Note: "Phase" is a mostly redundant concept, which represents the design-time for a job (whereas job was the runtime version of a phase). We've mostly removed the concept of "phase" from Azure Pipelines. Matrix and multi-config jobs are the only place where "phase" is still distinct from "job." One phase can instantiate multiple jobs, which differ only in their inputs.	No
System.PhaseDisplayName	The human-readable name given to a phase.	No
System.PhaseName	A string-based identifier for a job, typically used for expressing dependencies and accessing output variables.	No
System.PlanId	A string-based identifier for a single pipeline run.	No
System.PullRequest.IsFork	If the pull request is from a fork of the repository, this variable is set to `True`. Otherwise, it's set to `False`.	Yes
System.PullRequest.PullRequestId	The ID of the pull request that caused this build. For example: `17`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy).	No
System.PullRequest.PullRequestNumber	The number of the pull request that caused this build. This variable is populated for pull requests from GitHub that have a different pull request ID and pull request number. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.targetBranchName	The name of the target branch for a pull request. This variable can be used in a pipeline to conditionally execute tasks or steps based on the target branch of the pull request. For example, you might want to trigger a different set of tests or code analysis tools depending on the branch that the changes are being merged into.	No
System.PullRequest.SourceBranch	The branch that is being reviewed in a pull request. For example: `refs/heads/users/raisa/new-feature` for Azure Repos. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy). This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.SourceRepositoryURI	The URL to the repo that contains the pull request. For example: `https://dev.azure.com/ouraccount/_git/OurProject`.	No
System.PullRequest.TargetBranch	The branch that is the target of a pull request. For example: `refs/heads/main` when your repository is in Azure Repos and `main` when your repository is in GitHub. This variable is initialized only if the build ran because of a Git PR affected by a branch policy. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.StageAttempt	Set to 1 the first time this stage is attempted, and increments every time the stage is retried.	No
System.StageDisplayName	The human-readable name given to a stage.	No
System.StageName	A string-based identifier for a stage, typically used for expressing dependencies and accessing output variables.	No
System.TeamFoundationCollectionUri	The URI of the TFS collection or Azure DevOps organization. For example: `https://dev.azure.com/fabrikamfiber/`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.TeamProject	The name of the project that contains this build.	Yes
System.TeamProjectId	The ID of the project that this build belongs to.	Yes
System.TimelineId	A string-based identifier for the execution details and logs of a single pipeline run.	No
TF_BUILD	Set to `True` if the script is being run by a build task. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Checks variables (DevOps Server 2022)

Variable	Description
Checks.StageAttempt	Set to 1 the first time this stage is attempted, and increments every time the stage is retried. This variable can only be used within an approval or check for an environment. For example, you could use `$(Checks.StageAttempt)` within an Invoke REST API check.

Agent variables (DevOps Server 2020)

Note

Variable	Description
Agent.BuildDirectory	The local path on the agent where all folders for a given build pipeline are created. This variable has the same value as `Pipeline.Workspace`. For example: `/home/vsts/work/1`.
Agent.HomeDirectory	The directory the agent is installed into. This contains the agent software. For example: `c:\agent`.
Agent.Id	The ID of the agent.
Agent.JobName	The name of the running job. This will usually be "Job" or "__default", but in multi-config scenarios, will be the configuration.
Agent.JobStatus	The status of the build. `Canceled` `Failed` `Succeeded` `SucceededWithIssues` (partially successful) `Skipped` (last job) The environment variable should be referenced as `AGENT_JOBSTATUS`. The older `agent.jobstatus` is available for backwards compatibility.
Agent.MachineName	The name of the machine on which the agent is installed.
Agent.Name	The name of the agent that is registered with the pool. If you're using a self-hosted agent, then this name gets set by you. See agents.
Agent.OS	The operating system of the agent host. Valid values are: `Windows_NT` `Darwin` `Linux` If you're running in a container, the agent host and container might be running different operating systems.
Agent.OSArchitecture	The operating system processor architecture of the agent host. Valid values are: `X86` `X64` `ARM processor`
Agent.TempDirectory	A temporary folder that is cleaned after each pipeline job. This directory is used by tasks such as .NET Core CLI task to hold temporary items like test results before they're published. For example: `/home/vsts/work/_temp` for Ubuntu.
Agent.ToolsDirectory	The directory used by tasks such as Node Tool Installer and Use Python Version to switch between multiple versions of a tool. These tasks add tools from this directory to `PATH` so that subsequent build steps can use them. Learn about managing this directory on a self-hosted agent.
Agent.WorkFolder	The working directory for this agent. For example: `c:\agent_work`. Note: This directory isn't guaranteed to be writable by pipeline tasks (for example, when mapped into a container)

Build variables (DevOps Server 2020)

Variable	Description	Available in templates?
Build.ArtifactStagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildId	The ID of the record for the completed build.	No
Build.BuildNumber	The name of the completed build, also known as the run number. You can specify what is included in this value. A typical use of this variable is to make it part of the label format, which you specify on the repository tab. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BuildUri	The URI for the build. For example: `vstfs:///Build/Build/1430`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.BinariesDirectory	The local path on the agent you can use as an output folder for compiled binaries. By default, new build pipelines aren't set up to clean this directory. You can define your build to clean it up on the Repository tab. For example: `c:\agent_work\1\b`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.ContainerId	The ID of the container for your artifact. When you upload an artifact in your pipeline, it's added to a container that is specific for that particular artifact.	No
Build.DefinitionName	The name of the build pipeline. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format will fail.	Yes
Build.DefinitionVersion	The version of the build pipeline.	Yes
Build.QueuedBy	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.QueuedById	See "How are the identity variables set?".	Yes
Build.Reason	The event that caused the build to run. `Manual`: A user manually queued the build. `IndividualCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in. `BatchedCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected. `Schedule`: Scheduled trigger. `ValidateShelveset`: A user manually queued the build of a specific TFVC shelveset. `CheckInShelveset`: Gated check-in trigger. `PullRequest`: The build was triggered by a Git branch policy that requires a build. `BuildCompletion`: The build was triggered by another build `ResourceTrigger`: The build was triggered by a resource trigger or it was triggered by another build. See Build pipeline triggers, Improve code quality with branch policies.	Yes
Build.Repository.Clean	The value you've selected for Clean in the source repository settings. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.LocalPath	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. Important note: If you check out only one Git repository, this path will be the exact path to the code. If you check out multiple repositories, the behavior is as follows (and might differ from the value of the Build.SourcesDirectory variable): If the checkout step for the self (primary) repository has no custom checkout path defined, or the checkout path is the multi-checkout default path `$(Pipeline.Workspace)/s/<RepoName>` for the self repository, the value of this variable will revert to its default value, which is `$(Pipeline.Workspace)/s`. If the checkout step for the self (primary) repository does have a custom checkout path defined (and it's not its multi-checkout default path), this variable will contain the exact path to the self repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.ID	The unique identifier of the repository. This won't change, even if the name of the repository does. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Name	The name of the triggering repository. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Provider	The type of the triggering repository. `TfsGit`: TFS Git repository `TfsVersionControl`: Team Foundation Version Control `Git`: Git repository hosted on an external server `GitHub` `Svn`: Subversion This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Tfvc.Workspace	Defined if your repository is Team Foundation Version Control. The name of the TFVC workspace used by the build agent. For example, if the Agent.BuildDirectory is `c:\agent_work\12` and the Agent.Id is `8`, the workspace name could be: `ws_12_8`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Uri	The URL for the triggering repository. For example: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.RequestedFor	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.	Yes
Build.RequestedForEmail	See "How are the identity variables set?".	Yes
Build.RequestedForId	See "How are the identity variables set?".	Yes
Build.SourceBranch	The branch of the triggering repo the build was queued for. Some examples: Git repo branch: `refs/heads/main` Git repo pull request: `refs/pull/1/merge` TFVC repo branch: `$/teamproject/main` TFVC repo gated check-in: `Gated_2016-06-06_05.20.51.4369;username@live.com` TFVC repo shelveset build: `myshelveset;username@live.com` When your pipeline is triggered by a tag: `refs/tags/your-tag-name` When you use this variable in your build number format, the forward slash characters (`/`) are replaced with underscore characters `_`). Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you cannot use this variable in your build number format.	Yes
Build.SourceBranchName	The name of the branch in the triggering repo the build was queued for. Git repo branch, pull request, or tag: The last path segment in the ref. For example, in `refs/heads/main` this value is `main`. In `refs/heads/feature/tools` this value is `tools`. In `refs/tags/your-tag-name` this value is `your-tag-name`. TFVC repo branch: The last path segment in the root server path for the workspace. For example, in `$/teamproject/main` this value is `main`. TFVC repo gated check-in or shelveset build is the name of the shelveset. For example, `Gated_2016-06-06_05.20.51.4369;username@live.com` or `myshelveset;username@live.com`. Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.	Yes
Build.SourcesDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. Important note: If you check out only one Git repository, this path is the exact path to the code. If you check out multiple repositories, it reverts to its default value, which is `$(Pipeline.Workspace)/s`, even if the self (primary) repository is checked out to a custom path different from its multi-checkout default path `$(Pipeline.Workspace)/s/<RepoName>` (in this respect, the variable differs from the behavior of the Build.Repository.LocalPath variable). This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceVersion	The latest version control change of the triggering repo that is included in this build. Git: The commit ID. TFVC: the changeset. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
Build.SourceVersionMessage	The comment of the commit or changeset for the triggering repo. We truncate the message to the first line or 200 characters, whichever is shorter. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. Also, this variable is only available on the step level and is not available in the job or stage levels (that is, the message isn't extracted until the job had started and checked out the code). Note: This variable is available in TFS 2015.4. Note: The Build.SourceVersionMessage variable does not work with classic build pipelines in Bitbucket repositories when Batch changes while a build is in progress is enabled.	No
Build.StagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.Repository.Git.SubmoduleCheckout	The value you've selected for Checkout submodules on the repository tab. With multiple repos checked out, this value tracks the triggering repository's setting. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.SourceTfvcShelveset	Defined if your repository is Team Foundation Version Control. If you're running a gated build or a shelveset build, this is set to the name of the shelveset you're building. Note: This variable yields a value that is invalid for build use in a build number format.	No
Build.TriggeredBy.BuildId	If the build was triggered by another build, then this variable is set to the BuildID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.TriggeredBy.DefinitionId	If the build was triggered by another build, then this variable is set to the DefinitionID of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.TriggeredBy.DefinitionName	If the build was triggered by another build, then this variable is set to the name of the triggering build pipeline. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.TriggeredBy.BuildNumber	If the build was triggered by another build, then this variable is set to the number of the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Build.TriggeredBy.ProjectID	If the build was triggered by another build, then this variable is set to ID of the project that contains the triggering build. In Classic pipelines, this variable is triggered by a build completion trigger. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
Common.TestResultsDirectory	The local path on the agent where the test results are created. For example: `c:\agent_work\1\TestResults`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Pipeline variables (DevOps Server 2020)

Variable	Description
Pipeline.Workspace	Workspace directory for a particular pipeline. This variable has the same value as `Agent.BuildDirectory`. For example, `/home/vsts/work/1`.

Deployment job variables (DevOps Server 2020)

These variables are scoped to a specific Deployment job and will be resolved only at job execution time.

Variable	Description
Environment.Name	Name of the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `smarthotel-dev`.
Environment.Id	ID of the environment targeted in the deployment job. For example, `10`.
Environment.ResourceName	Name of the specific resource within the environment targeted in the deployment job to run the deployment steps and record the deployment history. For example, `bookings` which is a Kubernetes namespace that has been added as a resource to the environment `smarthotel-dev`.
Environment.ResourceId	ID of the specific resource within the environment targeted in the deployment job to run the deployment steps. For example, `4`.

System variables (DevOps Server 2020)

Variable	Description	Available in templates?
System.AccessToken	Use the OAuth token to access the REST API. Use System.AccessToken from YAML scripts. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.CollectionId	The GUID of the TFS collection or Azure DevOps organization	Yes
System.CollectionUri	A string Team Foundation Server collection URI.	Yes
System.DefaultWorkingDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s` By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No
System.DefinitionId	The ID of the build pipeline.	Yes
System.HostType	Set to `build` if the pipeline is a build. For a release, the values are `deployment` for a Deployment group job, `gates` during evaluation of gates, and `release` for other (Agent and Agentless) jobs.	Yes
System.JobAttempt	Set to 1 the first time this job is attempted, and increments every time the job is retried.	No
System.JobDisplayName	The human-readable name given to a job.	No
System.JobId	A unique identifier for a single attempt of a single job. The value is unique to the current pipeline.	No
System.JobName	The name of the job, typically used for expressing dependencies and accessing output variables.	No
System.PhaseAttempt	Set to 1 the first time this phase is attempted, and increments every time the job is retried. Note: "Phase" is a mostly redundant concept, which represents the design-time for a job (whereas job was the runtime version of a phase). We've mostly removed the concept of "phase" from Azure Pipelines. Matrix and multi-config jobs are the only place where "phase" is still distinct from "job". One phase can instantiate multiple jobs, which differ only in their inputs.	No
System.PhaseDisplayName	The human-readable name given to a phase.	No
System.PhaseName	A string-based identifier for a job, typically used for expressing dependencies and accessing output variables.	No
System.StageAttempt	Set to 1 the first time this stage is attempted, and increments every time the job is retried.	No
System.StageDisplayName	The human-readable name given to a stage.	No
System.StageName	A string-based identifier for a stage, typically used for expressing dependencies and accessing output variables.	Yes
System.PullRequest.IsFork	If the pull request is from a fork of the repository, this variable is set to `True`. Otherwise, it's set to `False`.	Yes
System.PullRequest.PullRequestId	The ID of the pull request that caused this build. For example: `17`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy).	No
System.PullRequest.PullRequestNumber	The number of the pull request that caused this build. This variable is populated for pull requests from GitHub which have a different pull request ID and pull request number. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.targetBranchName	The name of the target branch for a pull request. This variable can be used in a pipeline to conditionally execute tasks or steps based on the target branch of the pull request. For example, you might want to trigger a different set of tests or code analysis tools depending on the branch that the changes are being merged into.	No
System.PullRequest.SourceBranch	The branch that is being reviewed in a pull request. For example: `refs/heads/users/raisa/new-feature`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy). This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.PullRequest.SourceCommitId	The commit that is being reviewed in a pull request. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy). This variable is only available in a YAML pipeline if the PR is affected by a branch policy.
System.PullRequest.SourceRepositoryURI	The URL to the repo that contains the pull request. For example: `https://dev.azure.com/ouraccount/_git/OurProject`.	No
System.PullRequest.TargetBranch	The branch that is the target of a pull request. For example: `refs/heads/main` when your repository is in Azure Repos and `main` when your repository is in GitHub. This variable is initialized only if the build ran because of a Git PR affected by a branch policy. This variable is only available in a YAML pipeline if the PR is affected by a branch policy.	No
System.TeamFoundationCollectionUri	The URI of the team foundation collection. For example: `https://dev.azure.com/fabrikamfiber/`. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	Yes
System.TeamProject	The name of the project that contains this build.	Yes
System.TeamProjectId	The ID of the project that this build belongs to.	Yes
TF_BUILD	Set to `True` if the script is being run by a build task. This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.	No

Agent variables (DevOps Server 2019)

Note

Variable	Description
Agent.BuildDirectory	The local path on the agent where all folders for a given build pipeline are created. For example: `c:\agent_work\1`.
Agent.HomeDirectory	The directory the agent is installed into. This contains the agent software. For example: `c:\agent`.
Agent.Id	The ID of the agent.
Agent.JobName	The name of the running job. This will usually be "Job" or "__default", but in multi-config scenarios, will be the configuration.
Agent.JobStatus	The status of the build. `Canceled` `Failed` `Succeeded` `SucceededWithIssues` (partially successful) `Skipped` (last job) The environment variable should be referenced as `AGENT_JOBSTATUS`. The older `agent.jobstatus` is available for backwards compatibility.
Agent.MachineName	The name of the machine on which the agent is installed.
Agent.Name	The name of the agent that is registered with the pool. If you're using a self-hosted agent, then this name get set by you. See agents.
Agent.OS	The operating system of the agent host. Valid values are: `Windows_NT` `Darwin` `Linux` If you're running in a container, the agent host and container may be running different operating systems.
Agent.OSArchitecture	The operating system processor architecture of the agent host. Valid values are: `X86` `X64` `ARM processor`
Agent.TempDirectory	A temporary folder that is cleaned after each pipeline job. This directory is used by tasks such as .NET Core CLI task to hold temporary items like test results before they're published.
Agent.ToolsDirectory	The directory used by tasks such as Node Tool Installer and Use Python Version to switch between multiple versions of a tool. These tasks add tools from this directory to `PATH` so that subsequent build steps can use them. Learn about managing this directory on a self-hosted agent.
Agent.WorkFolder	The working directory for this agent. For example: `c:\agent_work`. This directory isn't guaranteed to be writable by pipeline tasks (for example, when mapped into a container).

Build variables (DevOps Server 2019)

Variable	Description
Build.ArtifactStagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.BuildId	The ID of the record for the completed build.
Build.BuildNumber	The name of the completed build. You can specify the build number format that generates this value in the pipeline options. A typical use of this variable is to make it part of the label format, which you specify on the repository tab. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.BuildUri	The URI for the build. For example: `vstfs:///Build/Build/1430`. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.BinariesDirectory	The local path on the agent you can use as an output folder for compiled binaries. By default, new build pipelines aren't set up to clean this directory. You can define your build to clean it up on the Repository tab. For example: `c:\agent_work\1\b`. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.DefinitionName	The name of the build pipeline. Note: This value can contain whitespace or other invalid label characters. In these cases, the label format will fail.
Build.DefinitionVersion	The version of the build pipeline.
Build.QueuedBy	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.
Build.QueuedById	See "How are the identity variables set?".
Build.Reason	The event that caused the build to run. `Manual`: A user manually queued the build. `IndividualCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in. `BatchedCI`: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected. `Schedule`: Scheduled trigger. `ValidateShelveset`: A user manually queued the build of a specific TFVC shelveset. `CheckInShelveset`: Gated check-in trigger. `PullRequest`: The build was triggered by a Git branch policy that requires a build. `BuildCompletion`: The build was triggered by another build. See Build pipeline triggers, Improve code quality with branch policies.
Build.Repository.Clean	The value you've selected for Clean in the source repository settings. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.Repository.LocalPath	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s` By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. This variable is synonymous with Build.SourcesDirectory.
Build.Repository.Name	The name of the repository. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.Repository.Provider	The type of repository you selected. `TfsGit`: TFS Git repository `TfsVersionControl`: Team Foundation Version Control `Git`: Git repository hosted on an external server `GitHub` `Svn`: Subversion This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.Repository.Tfvc.Workspace	Defined if your repository is Team Foundation Version Control. The name of the TFVC workspace used by the build agent. For example, if the Agent.BuildDirectory is `c:\agent_work\12` and the Agent.Id is `8`, the workspace name could be: `ws_12_8`. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.Repository.Uri	The URL for the repository. For example: Git: https://dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.RequestedFor	See "How are the identity variables set?". Note: This value can contain whitespace or other invalid label characters. In these cases, the label format fails.
Build.RequestedForEmail	See "How are the identity variables set?".
Build.RequestedForId	See "How are the identity variables set?".
Build.SourceBranch	The branch the build was queued for. Some examples: Git repo branch: `refs/heads/main` Git repo pull request: `refs/pull/1/merge` TFVC repo branch: `$/teamproject/main` TFVC repo gated check-in: `Gated_2016-06-06_05.20.51.4369;username@live.com` TFVC repo shelveset build: `myshelveset;username@live.com` When you use this variable in your build number format, the forward slash characters (`/`) are replaced with underscore characters (`_`). Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.
Build.SourceBranchName	The name of the branch the build was queued for. Git repo branch, pull request, or tag: The last path segment in the ref. For example, in `refs/heads/main` this value is `main`. In `refs/heads/feature/tools` this value is `tools`. In `refs/tags/your-tag-name` this value is `your-tag-name`. TFVC repo branch: The last path segment in the root server path for the workspace. For example in `$/teamproject/main` this value is `main`. TFVC repo gated check-in or shelveset build is the name of the shelveset. For example, `Gated_2016-06-06_05.20.51.4369;username@live.com` or `myshelveset;username@live.com`. Note: In TFVC, if you're running a gated check-in build or manually building a shelveset, you can't use this variable in your build number format.
Build.SourcesDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s`. By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. This variable is synonymous with Build.Repository.LocalPath.
Build.SourceVersion	The latest version control change that is included in this build. Git: The commit ID. TFVC: the changeset. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.SourceVersionMessage	The comment of the commit or changeset. We truncate the message to the first line or 200 characters, whichever is shorter. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag. Note: This variable is available in TFS 2015.4. Note: The Build.SourceVersionMessage variable does not work with classic build pipelines in Bitbucket repositories when Batch changes while a build is in progress is enabled.
Build.StagingDirectory	The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: `c:\agent_work\1\a`. A typical way to use this folder is to publish your build artifacts with the Copy files and Publish build artifacts tasks. Note: Build.ArtifactStagingDirectory and Build.StagingDirectory are interchangeable. This directory is purged before each new build, so you don't have to clean it up yourself. See Artifacts in Azure Pipelines. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.Repository.Git.SubmoduleCheckout	The value you've selected for Checkout submodules on the repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.SourceTfvcShelveset	Defined if your repository is Team Foundation Version Control. If you're running a gated build or a shelveset build, this is set to the name of the shelveset you're building. Note: This variable yields a value that is invalid for build use in a build number format.
Build.TriggeredBy.BuildId	If the build was triggered by another build, then this variable is set to the BuildID of the triggering build. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.TriggeredBy.DefinitionId	If the build was triggered by another build, then this variable is set to the DefinitionID of the triggering build. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.TriggeredBy.DefinitionName	If the build was triggered by another build, then this variable is set to the name of the triggering build pipeline. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.TriggeredBy.BuildNumber	If the build was triggered by another build, then this variable is set to the number of the triggering build. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Build.TriggeredBy.ProjectID	If the build was triggered by another build, then this variable is set to ID of the project that contains the triggering build. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
Common.TestResultsDirectory	The local path on the agent where the test results are created. For example: `c:\agent_work\1\TestResults`. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.

System variables (DevOps Server 2019)

Example PowerShell script: access REST API

Variable	Description
System.AccessToken	Use the OAuth token to access the REST API. Use System.AccessToken from YAML scripts. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
System.CollectionId	The GUID of the TFS collection or Azure DevOps organization
System.DefaultWorkingDirectory	The local path on the agent where your source code files are downloaded. For example: `c:\agent_work\1\s` By default, new build pipelines update only the changed files. You can modify how files are downloaded on the Repository tab. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
System.DefinitionId	The ID of the build pipeline.
System.HostType	Set to `build` if the pipeline is a build. For a release, the values are `deployment` for a Deployment group job and `release` for an Agent job.
System.PullRequest.IsFork	If the pull request is from a fork of the repository, this variable is set to `True`. Otherwise, it is set to `False`.
System.PullRequest.PullRequestId	The ID of the pull request that caused this build. For example: `17`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy.)
System.PullRequest.PullRequestNumber	The number of the pull request that caused this build. This variable is populated for pull requests from GitHub, which have a different pull request ID and pull request number.
System.PullRequest.SourceBranch	The branch that is being reviewed in a pull request. For example: `refs/heads/users/raisa/new-feature`. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy.)
System.PullRequest.SourceCommitId	The commit that is being reviewed in a pull request. (This variable is initialized only if the build ran because of a Git PR affected by a branch policy.)
System.PullRequest.SourceRepositoryURI	The URL to the repo that contains the pull request. For example: `https://dev.azure.com/ouraccount/_git/OurProject`. (This variable is initialized only if the build ran because of a Azure Repos Git PR affected by a branch policy. It isn't initialized for GitHub PRs.)
System.PullRequest.TargetBranch	The branch that is the target of a pull request. For example: `refs/heads/main`. This variable is initialized only if the build ran because of a Git PR affected by a branch policy.
System.TeamFoundationCollectionUri	The URI of the team foundation collection. For example: `https://dev.azure.com/fabrikamfiber/`. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.
System.TeamProject	The name of the project that contains this build.
System.TeamProjectId	The ID of the project that this build belongs to.
TF_BUILD	Set to `True` if the script is being run by a build task. This variable is agent-scoped. It can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.

How are the identity variables set?

The value depends on what caused the build and are specific to Azure Repos repositories.

If the build is triggered...	Then the Build.QueuedBy and Build.QueuedById values are based on...	Then the Build.RequestedFor and Build.RequestedForId values are based on...
In Git or by the Continuous integration (CI) triggers	The system identity, for example: `[DefaultCollection]\Project Collection Service Accounts`	The person who pushed or checked in the changes.
In Git or by a branch policy build.	The system identity, for example: `[DefaultCollection]\Project Collection Service Accounts`	The person who checked in the changes.
In TFVC by a gated check-in trigger	The person who checked in the changes.	The person who checked in the changes.
In Git or TFVC by the Scheduled triggers	The system identity, for example: `[DefaultCollection]\Project Collection Service Accounts`	The system identity, for example: `[DefaultCollection]\Project Collection Service Accounts`
Because you clicked the Queue build button	You	You

Ask Copilot to generate a stage with a condition based on variable values

Use Copilot to generate a stage with a condition determined by the value of a variable.

This example prompt defines a stage that runs when Agent.JobStatus indicates that the previous stage ran successfully:

Create a new Azure DevOps stage that only runs when Agent.JobStatus is Succeeded or SucceededWithIssues.

You can customize the prompt to use values that meet your requirements. For example, you can ask for help creating a stage that only runs when a pipeline fails.

Note

GitHub Copilot is powered by AI, so surprises and mistakes are possible. Make sure to verify any generated code or suggestions. For more information about the general use of GitHub Copilot, product impact, human oversight, and privacy, see GitHub Copilot FAQs.

Share via

Use predefined variables

Build.Clean

System.AccessToken

System.Debug

Agent variables (DevOps Services)

Build variables (DevOps Services)

Pipeline variables (DevOps Services)

Deployment job variables (DevOps Services)

System variables (DevOps Services)

Checks variables (DevOps Services)

Agent variables (DevOps Server 2022)

Build variables (DevOps Server 2022)

Pipeline variables (DevOps Server 2022)

Deployment job variables (DevOps Server 2022)

System variables (DevOps Server 2022)

Checks variables (DevOps Server 2022)

Agent variables (DevOps Server 2020)

Build variables (DevOps Server 2020)

Pipeline variables (DevOps Server 2020)

Deployment job variables (DevOps Server 2020)

System variables (DevOps Server 2020)

Agent variables (DevOps Server 2019)

Build variables (DevOps Server 2019)

System variables (DevOps Server 2019)

How are the identity variables set?

Ask Copilot to generate a stage with a condition based on variable values

Feedback

Additional resources