Condividi tramite


Use predefined variables

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

Learn more about working with variables.

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.

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.

  1. Edit your pipeline.

  2. Select Variables.

  3. Add a new variable with the name System.Debug and value true.

    Set System Debug to true

  4. 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'

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

Agent variables (DevOps Server 2019)

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. 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.
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:
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.
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 For more information about the agent directory structure, see Agent directory structure.

On self-hosted agents, new build pipelines update only the changed files by default. 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. It can't be used 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