Usar variáveis predefinidas

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

As variáveis oferecem uma forma conveniente de inserir os principais bits de dados em várias partes do pipeline. Esta é uma lista de variáveis predefinidas disponíveis para uso. Pode haver outras variáveis predefinidas, mas elas são principalmente para uso interno.

Essas variáveis são definidas automaticamente pelo sistema e somente leitura. (As exceções são Build.Clean e System.Debug.)

Em pipelines YAML, você pode referenciar variáveis predefinidas como variáveis de ambiente. Por exemplo, a variável Build.ArtifactStagingDirectory se torna BUILD_ARTIFACTSTAGINGDIRECTORY.

Para pipelines clássicos, você pode usar variáveis de versão em suas tarefas de implantação para compartilhar as informações comuns (por exemplo, Nome do Ambiente, Grupo de Recursos etc.).

Saiba mais sobre como trabalhar com variáveis.

Build.Clean

Essa é uma variável preterida que modifica como o agente de build limpa a origem. Para saber como limpar a origem, consulte Limpar o repositório local no agente.

System.AccessToken

System.AccessToken é uma variável especial que carrega o token de segurança usado pelo build em execução.

No YAML, você deve mapear System.AccessToken explicitamente para o pipeline usando uma variável. Você pode fazer isso no nível da etapa ou da tarefa:

steps:
  - script: |
      echo "Using System.AccessToken to authenticate"
      git clone https://$(System.AccessToken)@dev.azure.com/yourorganization/yourproject/_git/yourrepository
    displayName: 'Clone repository using System.AccessToken'
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Você pode configurar o escopo padrão para System.AccessToken usar o escopo de autorização de trabalho de build.

System.Debug

Para logs mais detalhados para depurar problemas de pipeline, defina System.Debug como true.

  1. Edite seu pipeline.

  2. Selecione Variáveis.

  3. Adicione uma nova variável com o nome System.Debug e o valor true.

    Definir depuração do sistema como true

  4. Salve a nova variável.

Definir System.Debug para true configura logs detalhados para todas as execuções. Você também pode configurar logs detalhados para uma única execução com a caixa de seleção Habilitar diagnóstico do sistema.

Você também pode definir System.Debug como true como uma variável em um pipeline ou modelo.

variables:
  system.debug: 'true'

Quando System.Debug é definido como true, uma variável extra chamada Agent.Diagnostic é definida como true. Quando Agent.Diagnostic for true, o agente coleta mais logs que podem ser usados para solucionar problemas de rede para os agentes auto-hospedados. Para obter mais informações,confira Diagnóstico de rede para agentes auto-hospedados.

Observação

A variável Agent.Diagnostic está disponível com o Agent v2.200.0 e superior.

Para obter mais informações, consulte Revisar logs para diagnosticar problemas de pipeline.

Variáveis do agente (DevOps Services)

Observação

Você pode usar variáveis de agente como variáveis de ambiente em seus scripts e como parâmetros em suas tarefas de build. Você não pode usá-los para personalizar o número de build ou para aplicar um rótulo ou marca de controle de versão.

Variável Descrição
Agent.BuildDirectory O caminho local no agente onde todas as pastas de um determinado pipeline de build são criadas. Essa variável tem o mesmo valor que Pipeline.Workspace. Por exemplo: /home/vsts/work/1.
Agent.ContainerMapping Um mapeamento de nomes de recursos de contêiner no YAML para suas IDs do Docker em runtime.

O exemplo segue a tabela.
Agent.HomeDirectory O diretório no qual o agente está instalado. Isso contém o software do agente. Por exemplo: c:\agent.
Agent.Id A ID do agente.
Agent.JobName O nome do trabalho em execução. Isso geralmente será "Job"; ou "__default", mas em cenários de várias configurações, será a configuração.
Agent.JobStatus O status do build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (parcialmente bem-sucedido)
  • Skipped (último trabalho)
A variável de ambiente deve ser referenciada como AGENT_JOBSTATUS. O agent.jobstatus mais antigo está disponível para compatibilidade com versões anteriores.
Agent.MachineName O nome do computador no qual o agente está instalado.
Agent.Name O nome do agente registrado no pool.

Se você estiver usando um agente auto-hospedado, esse nome será especificado por você. Consulte agentes.
Agent.OS O sistema operacional do host do agente. Os valores válidos são:
  • Windows_NT
  • Darwin
  • Linux
Se você estiver executando em um contêiner, o host e o contêiner do agente poderão estar executando sistemas operacionais diferentes.
Agent.OSArchitecture A arquitetura do processador do sistema operacional do host do agente. Os valores válidos são:
  • X86
  • X64
  • ARM
Agent.TempDirectory Uma pasta temporária que é limpa após cada trabalho de pipeline. Esse diretório é usado por tarefas como Tarefa da CLI do .NET Core para manter itens temporários, como resultados de teste antes de serem publicados.

Por exemplo: /home/vsts/work/_temp do Ubuntu.
Agent.ToolsDirectory O diretório usado por tarefas como o Instalador de Ferramentas do Node e a Versão do Python para alternar entre várias versões de uma ferramenta.

Essas tarefas adicionam ferramentas desse diretório a PATH para que as etapas de compilação subsequentes possam usá-las.

Saiba mais sobre como gerenciar esse diretório em um agente auto-hospedado.
Agent.WorkFolder O diretório de trabalho para esse agente.

Por exemplo: c:\agent_work.

Observação: esse diretório não tem garantia de ser gravável por tarefas de pipeline (por exemplo, quando mapeado para um contêiner)

Exemplo de Agent.ContainerMapping:

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

Variáveis de build (DevOps Services)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
Build.ArtifactStagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildId A ID do registro para o build concluído. Não
Build.BuildNumber O nome do build concluído, também conhecido como o número de execução. Você pode especificar o que está incluído nesse valor.

Um uso típico dessa variável é torná-la parte do formato de rótulo, que você especifica na guia repositório.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildUri O URI do build. Por exemplo: vstfs:///Build/Build/1430.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BinariesDirectory O caminho local no agente que você pode usar como uma pasta de saída para binários compilados.

Por padrão, novos pipelines de build não são configurados como limpos esse diretório. Você pode definir seu build para limpá-lo na guia Repositório.

Por exemplo: c:\agent_work\1\b.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.ContainerId A ID do contêiner para o artefato. Quando você carrega um artefato no seu pipeline, ele é adicionado a um contêiner específico nesse artefato específico. Não
Build.CronSchedule.DisplayName O displayName da programação cron que acionou a execução do pipeline. Essa variável só será definida se a execução do pipeline for disparada por um gatilho agendado do YAML. Para obter mais informações, consulte definição schedules.cron – variável Build.CronSchedule.DisplayName Sim
Build.DefinitionName O nome do pipeline de build.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.DefinitionVersion A versão do pipeline de build. Sim
Build.QueuedBy Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.QueuedById Confira "Como as variáveis de identidade são definidas?". Sim
Build.Reason O evento que causou a execução do build.
  • Manual: um usuário colocava manualmente o build em fila.
  • IndividualCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC.
  • BatchedCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC e as alterações do Lote foram selecionadas.
  • Schedule: gatilho agendado.
  • ValidateShelveset: um usuário colocava manualmente em fila a compilação de um check-in particular do TFVC específico.
  • CheckInShelveset: gatilho de check-in restrito.
  • PullRequest: o build foi disparado por uma política de branch do Git que requer um build.
  • BuildCompletion: o build foi disparado por outro build
  • ResourceTrigger: o build foi disparado por um gatilho de recurso ou foi disparado por outro build.
Confira Gatilhos de pipeline de build, Melhorar a qualidade do código com políticas de branch.
Sim
Build.Repository.Clean O valor selecionado para Limpar nas configurações do repositório de origem.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.LocalPath O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Observação importante: se você fizer check-out de apenas um repositório Git, esse caminho será o caminho exato para o código.

Se você fizer check-out de vários repositórios, o comportamento será o seguinte (e poderá ser diferente do valor da variável Build.SourcesDirectory):
  • Se a etapa de check-out do repositório auto (primário) não tiver caminhos de check-out personalizados definidos ou o caminho de check-out for o caminho padrão de vários checkouts $(Pipeline.Workspace)/s/&<RepoName> para o auto repositório, o valor dessa variável será revertido para seu valor padrão, que é $(Pipeline.Workspace)/s.
  • Se a etapa de check-out do repositório auto (primário) tiver um caminho de check-out personalizado definido (e não for o caminho padrão de vários checkouts), essa variável conterá o caminho exato para o auto repositório.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.ID O identificador único do repositório.

Isso não será alterado, ainda que o nome do repositório seja.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Name O nome do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Provider O tipo do repositório de gatilho.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Tfvc.Workspace Definido se o repositório é Controle de Versão do Team Foundation. O nome do workspace do TFVC usado pelo agente de build.

Por exemplo, se o Agent.BuildDirectory for c:\agent_work\12 e o Agent.Id for 8, o nome do workspace poderá ser: ws_12_8

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Uri A URL do repositório de gatilho. Por exemplo:
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.RequestedFor Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.RequestedForEmail Confira "Como as variáveis de identidade são definidas?". Sim
Build.RequestedForId Confira "Como as variáveis de identidade são definidas?". Sim
Build.SourceBranch O branch do repositório de gatilho para o qual o build foi colocado na fila. Alguns exemplos:
  • Branch do repositório Git: refs/heads/main
  • Solicitação de pull do repositório Git: refs/pull/1/merge
  • Branch do repositório TFVC: $/teamproject/main
  • Check-in restrito do repositório TFVC: Gated_2016-06-06_05.20.51.4369;username@live.com
  • Build do check-in particular do repositório TFVC: myshelveset;username@live.com
  • Quando o pipeline é disparado por uma marca: refs/tags/your-tag-name
Quando você usa essa variável no formato de número de build, as barras (/) são substituídos por sublinhados _).

Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourceBranchName O nome do branch no repositório de gatilho para o qual o build foi colocado na fila.
  • Branch do repositório Git, solicitação de pull ou marca: o último segmento de linha na referência. Por exemplo, refs/heads/main nesse valor é main. Em refs/heads/feature/tools, esse valor é tools. Em refs/tags/your-tag-name, esse valor é your-tag-name.
  • Branch do repositório TFVC: o último segmento de linha no caminho do servidor raiz para o workspace. Por exemplo, em $/teamproject/main, esse valor é main.
  • Check-in restrito ou build de check-in particular do repositório TFVC é o nome do check-in particular. Por exemplo, Gated_2016-06-06_05.20.51.4369;username@live.com ou myshelveset;username@live.com.
Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourcesDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados.

Observação importante: se você fizer check-out de apenas um repositório Git, esse caminho será o caminho exato para o código. Se você fizer check-out de vários repositórios, ele será revertido para seu valor padrão, que é $(Pipeline.Workspace)/s, mesmo que o repositório auto (primário) seja verificado em um caminho personalizado diferente do seu caminho padrão de vários check-outs $(Pipeline.Workspace)/s/<RepoName> (nesse aspecto, a variável difere do comportamento da variável Build.Repository.LocalPath).

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceVersion A alteração do controle de versão mais recente do repositório de gatilho incluído neste build.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
Build.SourceVersionMessage O comentário do commit ou do conjunto de alterações para o repositório de gatilho. Truncamos a mensagem para a primeira linha ou 200 caracteres, o que for menor.

Build.SourceVersionMessage corresponde à mensagem no commit de Build.SourceVersion. Commit de Build.SourceVersion de um build de PR é o commit de mesclagem (não o commit no branch de origem).

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Além disso, essa variável só está disponível no nível da etapa e não está disponível nos níveis de trabalho ou estágio (ou seja, a mensagem não é extraída até que o trabalho seja iniciado e o código seja verificado).

Observação: essa variável está disponível no TFS 2015.4.

Observação: a variável Build.SourceVersionMessage não funciona com pipelines de build clássicos nos repositórios do Bitbucket quando o Lote é alterado enquanto um build está em andamento estiver habilitado.
Não
Build.StagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Git.SubmoduleCheckout O valor selecionado para Fazer check-out de submódulos na guia Repositório. Com o check-out de vários repositórios, esse valor acompanha a configuração do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceTfvcShelveset Definido se o repositório é Controle de Versão do Team Foundation.

Se você estiver executando um build fechado ou um build de conjunto de prateleiras, isso será definido como o nome do conjunto de prateleiras que você está criando.

Observação: essa variável produz um valor inválido para uso de build em um formato de número de build.
Não
Build.TriggeredBy.BuildId Se o build tiver sido disparado por outro build, essa variável será definida como a BuildID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.DefinitionId Se o build tiver sido disparado por outro build, essa variável será definida como a DefinitionID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.DefinitionName Se o build tiver sido disparado por outro build, essa variável será definida como o nome do pipeline de build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.BuildNumber Se o build tiver sido disparado por outro build, essa variável será definida como o número do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.ProjectID Se o build tiver sido disparado por outro build, essa variável será definida como a ID do projeto que contém o build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Common.TestResultsDirectory O caminho local no agente em que os resultados do teste são criados. Por exemplo: c:\agent_work\1\TestResults.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis de pipeline (DevOps Services)

Variável Descrição
Pipeline.Workspace Diretório do workspace para um pipeline específico. Essa variável tem o mesmo valor que Agent.BuildDirectory. Por exemplo, /home/vsts/work/1.

Dica

Se você estiver usando pipelines de lançamento clássicos, poderá usar versões clássicas e variáveis de artefatos para armazenar e acessar dados em todo o pipeline.

Variáveis do trabalho de implantação (DevOps Services)

Essas variáveis têm escopo para um Trabalho de implantação específico e serão resolvidas somente no momento da execução do trabalho.

Variável Descrição
Environment.Name Nome do ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, smarthotel-dev.
Environment.Id ID do ambiente direcionado no trabalho de implantação. Por exemplo, 10.
Environment.ResourceName Nome do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, bookings que é um namespace do Kubernetes que foi adicionado como um recurso ao ambiente smarthotel-dev.
Environment.ResourceId ID do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação. Por exemplo, 4.
Strategy.Name O nome da estratégia de implantação: canary, runOnce ou rolling.
Strategy.CycleName O nome do ciclo atual em uma implantação. As opções são PreIteration, Iteration ou PostIteration.

Variáveis do sistema (DevOps Services)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
System.AccessToken Use o token OAuth para acessar a API REST.

Use System.AccessToken de scripts YAML.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.CollectionId O GUID da coleção TFS ou da organização do Azure DevOps. Sim
System.CollectionUri O URI da coleção TFS ou da organização do Azure DevOps. Por exemplo: https://dev.azure.com/fabrikamfiber/. Sim
System.DefaultWorkingDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.DefinitionId A ID do pipeline de build. Sim
System.HostType Defina como build se o pipeline for um build. Para uma versão, os valores são deployment para um trabalho de grupo de implantação, gates durante a avaliação de portões e release para outros trabalhos (com e sem agente). Sim
System.JobAttempt Defina como 1 na primeira vez em que esse trabalho é tentado e incremente sempre que o trabalho for repetido. Não
System.JobDisplayName O nome legível por humanos atribuído a um trabalho. Não
System.JobId Um identificador exclusivo para uma única tentativa de um único trabalho. O valor é exclusivo para o pipeline atual. Não
System.JobName O nome do trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.OidcRequestUri Gere um idToken para autenticação com o Entra ID usando o OpenID Connect (OIDC). Saiba mais. Sim
System.PhaseAttempt Defina como 1 na primeira vez em que essa fase é tentada e incremente sempre que o trabalho for repetido.

Observação: "Fase" é um conceito redundante que representa o tempo de design de um trabalho (enquanto o trabalho era a versão de runtime de uma fase). Removemos principalmente o conceito de "fase" do Azure Pipelines. Os trabalhos de matriz e várias configurações são o único lugar em que a "fase" ainda é diferente de "trabalho". Uma fase pode instanciar vários trabalhos que diferem apenas nas suas entradas.
Não
System.PhaseDisplayName O nome legível por humanos atribuído a uma fase. Não
System.PhaseName Um identificador baseado em cadeia de caracteres para um trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.PlanId Um identificador baseado em cadeia de caracteres para uma única execução de pipeline. Não
System.PullRequest.IsFork Se a solicitação de pull for de uma bifurcação do repositório, essa variável será definida como True.

Caso contrário, ele será definido como False.
Sim
System.PullRequest.PullRequestId A ID da solicitação de pull que causou esse build. Por exemplo: 17. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Não
System.PullRequest.PullRequestNumber O número da solicitação de pull que causou esse build. Essa variável é preenchida para solicitações de pull do GitHub que tenham uma ID de solicitação de pull diferente e um número de solicitação de pull. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.targetBranchName O nome do branch de destino para uma solicitação de pull. Essa variável pode ser usada em um pipeline para executar condicionalmente tarefas ou etapas com base no branch de destino da solicitação de pull. Por exemplo, talvez você queira disparar um conjunto diferente de testes ou ferramentas de análise de código, dependendo do branch no qual as alterações estão sendo mescladas. Não
System.PullRequest.SourceBranch O branch que está sendo revisado em uma solicitação de pull. Por exemplo: refs/heads/users/raisa/new-feature para o Azure Repos. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.SourceCommitId O branch que está sendo revisado em uma solicitação de pull. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch.
System.PullRequest.SourceRepositoryURI A URL para o repositório que contém a solicitação de pull. Por exemplo: https://dev.azure.com/ouraccount/_git/OurProject. Não
System.PullRequest.TargetBranch O branch que é o destino de uma solicitação de pull. Por exemplo: refs/heads/main quando o repositório está no Azure Repos e main quando o repositório está no GitHub. Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.StageAttempt Defina como 1 na primeira vez em que esse estágio é tentado e incremente sempre que o trabalho for repetido. Não
System.StageDisplayName O nome legível por humanos atribuído a um estágio. Não
System.StageName Um identificador baseado em cadeia de caracteres para um estágio, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.TeamFoundationCollectionUri O URI da coleção TFS ou da organização do Azure DevOps. Por exemplo: https://dev.azure.com/fabrikamfiber/.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.TeamProject O nome do projeto que contém esse build. Sim
System.TeamProjectId A ID do projeto ao qual este build pertence. Sim
System.TimelineId Um identificador baseado em cadeia de caracteres para os detalhes de execução e logs de uma única execução de pipeline. Não
TF_BUILD Defina como True se o script estiver sendo executado por uma tarefa de build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis de verificação (DevOps Services)

Variável Descrição
Checks.StageAttempt Defina como 1 na primeira vez em que esse estágio é tentado e incremente sempre que o estágio for repetido.

Essa variável só pode ser usada em uma aprovação ou verificação de um ambiente. Por exemplo, você pode usar $(Checks.StageAttempt) em Invocar a verificação de API REST.

Adicione a tentativa de estágio como um parâmetro.

Variáveis do agente (DevOps Server 2022)

Observação

Você pode usar variáveis de agente como variáveis de ambiente em seus scripts e como parâmetros em suas tarefas de build. Você não pode usá-los para personalizar o número de build ou para aplicar um rótulo ou marca de controle de versão.

Variável Descrição
Agent.BuildDirectory O caminho local no agente onde todas as pastas de um determinado pipeline de build são criadas. Essa variável tem o mesmo valor que Pipeline.Workspace. Por exemplo: /home/vsts/work/1.
Agent.ContainerMapping Um mapeamento de nomes de recursos de contêiner no YAML para suas IDs do Docker em runtime. O exemplo segue a tabela.
Agent.HomeDirectory O diretório no qual o agente está instalado. Isso contém o software do agente. Por exemplo: c:\agent.
Agent.Id A ID do agente.
Agent.JobName O nome do trabalho em execução. Isso geralmente será "Job" ou "__default", mas em cenários de várias configurações, será a configuração.
Agent.JobStatus O status do build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (parcialmente bem-sucedido)
  • Skipped (último trabalho)
A variável de ambiente deve ser referenciada como AGENT_JOBSTATUS. O agent.jobstatus mais antigo está disponível para compatibilidade com versões anteriores.
Agent.MachineName O nome do computador no qual o agente está instalado.
Agent.Name O nome do agente registrado no pool.

Se você estiver usando um agente auto-hospedado, esse nome será especificado por você. Consulte agentes.
Agent.OS O sistema operacional do host do agente. Os valores válidos são:
  • Windows_NT
  • Darwin
  • Linux
Se você estiver executando em um contêiner, o host e o contêiner do agente poderão estar executando sistemas operacionais diferentes.
Agent.OSArchitecture A arquitetura do processador do sistema operacional do host do agente. Os valores válidos são:
  • X86
  • X64
  • ARM
Agent.TempDirectory Uma pasta temporária que é limpa após cada trabalho de pipeline. Esse diretório é usado por tarefas como Tarefa da CLI do .NET Core para manter itens temporários, como resultados de teste antes de serem publicados.

Por exemplo: /home/vsts/work/_temp do Ubuntu.
Agent.ToolsDirectory O diretório usado por tarefas como o Instalador de Ferramentas do Node e a Versão do Python para alternar entre várias versões de uma ferramenta.

Essas tarefas adicionam ferramentas desse diretório a PATH para que as etapas de compilação subsequentes possam usá-las.

Saiba mais sobre como gerenciar esse diretório em um agente auto-hospedado.
Agent.WorkFolder O diretório de trabalho para esse agente. Por exemplo: c:\agent_work.

Observação: esse diretório não tem garantia de ser gravável por tarefas de pipeline (por exemplo, quando mapeado para um contêiner).

Exemplo de Agent.ContainerMapping:

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

Variáveis de build (DevOps Server 2022)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
Build.ArtifactStagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildId A ID do registro para o build concluído. Não
Build.BuildNumber O nome do build concluído, também conhecido como o número de execução. Você pode especificar o que está incluído nesse valor.

Um uso típico dessa variável é torná-la parte do formato de rótulo, que você especifica na guia repositório.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildUri O URI do build. Por exemplo: vstfs:///Build/Build/1430.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BinariesDirectory O caminho local no agente que você pode usar como uma pasta de saída para binários compilados.

Por padrão, novos pipelines de build não são configurados como limpos esse diretório. Você pode definir seu build para limpá-lo na guia Repositório.

Por exemplo: c:\agent_work\1\b.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.ContainerId A ID do contêiner para o artefato. Quando você carrega um artefato no seu pipeline, ele é adicionado a um contêiner específico nesse artefato específico. Não
Build.CronSchedule.DisplayName O displayName da programação cron que acionou a execução do pipeline. Essa variável só será definida se a execução do pipeline for disparada por um gatilho agendado do YAML. Para obter mais informações, consulte definição schedules.cron – variável Build.CronSchedule.DisplayName Essa variável está disponível no Azure DevOps Server 2022.1 e superior. Sim
Build.DefinitionName O nome do pipeline de build.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.DefinitionVersion A versão do pipeline de build. Sim
Build.QueuedBy Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.QueuedById Confira “Como as variáveis de identidade são definidas?”. Sim
Build.Reason O evento que causou a execução do build.
  • Manual: um usuário colocava manualmente o build em fila.
  • IndividualCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC.
  • BatchedCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC e as alterações do Lote foram selecionadas.
  • Schedule: gatilho agendado.
  • ValidateShelveset: um usuário colocava manualmente em fila a compilação de um check-in particular do TFVC específico.
  • CheckInShelveset: gatilho de check-in restrito.
  • PullRequest: o build foi disparado por uma política de branch do Git que requer um build.
  • BuildCompletion: o build foi disparado por outro build
  • ResourceTrigger: o build foi disparado por um gatilho de recurso ou foi disparado por outro build.
Confira Gatilhos de pipeline de build, Melhorar a qualidade do código com políticas de branch.
Sim
Build.Repository.Clean O valor selecionado para Limpar nas configurações do repositório de origem.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.LocalPath O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Observação importante: se você fizer check-out de apenas um repositório Git, esse caminho será o caminho exato para o código. Se você fizer check-out de vários repositórios, o comportamento será o seguinte (e poderá ser diferente do valor da variável Build.SourcesDirectory):
  • Se a etapa de check-out do repositório auto (primário) não tiver caminhos de check-out personalizados definidos ou o caminho de check-out for o caminho padrão de vários checkouts $(Pipeline.Workspace)/s/<RepoName> para o auto repositório, o valor dessa variável será revertido para seu valor padrão, que é $(Pipeline.Workspace)/s.
  • Se a etapa de check-out do repositório auto (primário) tiver um caminho de check-out personalizado definido (e não for o caminho padrão de vários checkouts), essa variável conterá o caminho exato para o auto repositório.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.ID O identificador único do repositório.

Isso não será alterado, ainda que o nome do repositório seja.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Name O nome do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Provider O tipo do repositório de gatilho.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Tfvc.Workspace Definido se o repositório é Controle de Versão do Team Foundation. O nome do workspace do TFVC usado pelo agente de build.

Por exemplo, se o Agent.BuildDirectory for c:\agent_work\12 e o Agent.Id for 8, o nome do workspace poderá ser: ws_12_8.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Uri A URL do repositório de gatilho. Por exemplo:Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão. Não
Build.RequestedFor Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.RequestedForEmail Confira "Como as variáveis de identidade são definidas?". Sim
Build.RequestedForId Confira "Como as variáveis de identidade são definidas?". Sim
Build.SourceBranch O branch do repositório de gatilho para o qual o build foi colocado na fila. Alguns exemplos:
  • Branch do repositório Git: refs/heads/main
  • Solicitação de pull do repositório Git: refs/pull/1/merge
  • Branch do repositório TFVC: $/teamproject/main
  • Check-in restrito do repositório TFVC: Gated_2016-06-06_05.20.51.4369;username@live.com
  • Build do check-in particular do repositório TFVC: myshelveset;username@live.com
  • Quando o pipeline é disparado por uma marca: refs/tags/your-tag-name
Quando você usa essa variável no formato de número de build, as barras (/) são substituídos por sublinhados _).

Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourceBranchName O nome do branch no repositório de gatilho para o qual o build foi colocado na fila.
  • Branch do repositório Git, solicitação de pull ou marca: o último segmento de linha na referência. Por exemplo, refs/heads/main nesse valor é main. Em refs/heads/feature/tools, esse valor é tools. Em refs/tags/your-tag-name, esse valor é your-tag-name.
  • Branch do repositório TFVC: o último segmento de linha no caminho do servidor raiz para o workspace. Por exemplo, em $/teamproject/main, esse valor é main.
  • Check-in restrito ou build de check-in particular do repositório TFVC é o nome do check-in particular. Por exemplo, Gated_2016-06-06_05.20.51.4369;username@live.com ou myshelveset;username@live.com.
Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourcesDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados.

Observação importante: se você fizer check-out de apenas um repositório Git, esse caminho será o caminho exato para o código. Se você fizer check-out de vários repositórios, ele será revertido para seu valor padrão, que é $(Pipeline.Workspace)/s, mesmo que o repositório auto (primário) seja verificado em um caminho personalizado diferente do seu caminho padrão de vários check-outs $(Pipeline.Workspace)/s/<RepoName> (nesse aspecto, a variável difere do comportamento da variável Build.Repository.LocalPath).

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceVersion A alteração do controle de versão mais recente do repositório de gatilho incluído neste build.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
Build.SourceVersionMessage O comentário do commit ou do conjunto de alterações para o repositório de gatilho. Truncamos a mensagem para a primeira linha ou 200 caracteres, o que for menor.

Build.SourceVersionMessage corresponde à mensagem no commit de Build.SourceVersion. Commit de Build.SourceVersion de um build de PR é o commit de mesclagem (não o commit no branch de origem).

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Além disso, essa variável só está disponível no nível da etapa e não está disponível nos níveis de trabalho ou estágio (ou seja, a mensagem não é extraída até que o trabalho seja iniciado e o código seja verificado).

Observação: essa variável está disponível no TFS 2015.4.

Observação: a variável Build.SourceVersionMessage não funciona com pipelines de build clássicos nos repositórios do Bitbucket quando o Lote é alterado enquanto um build está em andamento estiver habilitado.
Não
Build.StagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Git.SubmoduleCheckout O valor selecionado para Fazer check-out de submódulos na guia Repositório. Com o check-out de vários repositórios, esse valor acompanha a configuração do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceTfvcShelveset Definido se o repositório é Controle de Versão do Team Foundation.

Se você estiver executando um build fechado ou um build de conjunto de prateleiras, isso será definido como o nome do conjunto de prateleiras que você está criando.

Observação: essa variável produz um valor inválido para uso de build em um formato de número de build.
Não
Build.TriggeredBy.BuildId Se o build tiver sido disparado por outro build, essa variável será definida como a BuildID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.DefinitionId Se o build tiver sido disparado por outro build, essa variável será definida como a DefinitionID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.DefinitionName Se o build tiver sido disparado por outro build, essa variável será definida como o nome do pipeline de build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.BuildNumber Se o build tiver sido disparado por outro build, essa variável será definida como o número do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Build.TriggeredBy.ProjectID Se o build tiver sido disparado por outro build, essa variável será definida como a ID do projeto que contém o build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Se você estiver disparando um pipeline YAML usando resources, deverá usar as variáveis de recursos em vez disso.
Não
Common.TestResultsDirectory O caminho local no agente em que os resultados do teste são criados. Por exemplo: c:\agent_work\1\TestResults.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis de pipeline (DevOps Server 2022)

Variável Descrição
Pipeline.Workspace Diretório do workspace para um pipeline específico. Essa variável tem o mesmo valor que Agent.BuildDirectory. Por exemplo, /home/vsts/work/1.

Dica

Se você estiver usando pipelines de lançamento clássicos, poderá usar versões clássicas e variáveis de artefatos para armazenar e acessar dados em todo o pipeline.

Variáveis do trabalho de implantação (DevOps Server 2022)

Essas variáveis têm escopo para um Trabalho de implantação específico e serão resolvidas somente no momento da execução do trabalho.

Variável Descrição
Environment.Name Nome do ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, smarthotel-dev.
Environment.Id ID do ambiente direcionado no trabalho de implantação. Por exemplo, 10.
Environment.ResourceName Nome do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, bookings que é um namespace do Kubernetes que foi adicionado como um recurso ao ambiente smarthotel-dev.
Environment.ResourceId ID do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação. Por exemplo, 4.
Strategy.Name O nome da estratégia de implantação: canary, runOnce ou rolling.
Strategy.CycleName O nome do ciclo atual em uma implantação. As opções são PreIteration, Iteration ou PostIteration.

Variáveis do sistema (DevOps Server 2022)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
System.AccessToken Use o token OAuth para acessar a API REST.

Use System.AccessToken de scripts YAML.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.CollectionId O GUID da coleção TFS ou da organização do Azure DevOps. Sim
System.CollectionUri O URI da coleção TFS ou da organização do Azure DevOps. Por exemplo: https://dev.azure.com/fabrikamfiber/. Sim
System.DefaultWorkingDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.DefinitionId A ID do pipeline de build. Sim
System.HostType Defina como build se o pipeline for um build. Para uma versão, os valores são deployment para um trabalho de grupo de implantação, gates durante a avaliação de portões e release para outros trabalhos (com e sem agente). Sim
System.JobAttempt Defina como 1 na primeira vez em que esse trabalho é tentado e incremente sempre que o trabalho for repetido. Não
System.JobDisplayName O nome legível por humanos atribuído a um trabalho. Não
System.JobId Um identificador exclusivo para uma única tentativa de um único trabalho. O valor é exclusivo para o pipeline atual. Não
System.JobName O nome do trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.PhaseAttempt Defina como 1 na primeira vez em que essa fase é tentada e incremente sempre que o trabalho for repetido.

Observação: "Fase" é um conceito redundante que representa o tempo de design de um trabalho (enquanto o trabalho era a versão de runtime de uma fase). Removemos principalmente o conceito de "fase" do Azure Pipelines. Os trabalhos de matriz e várias configurações são o único lugar em que a "fase" ainda é diferente de "trabalho". Uma fase pode instanciar vários trabalhos que diferem apenas nas suas entradas.
Não
System.PhaseDisplayName O nome legível por humanos atribuído a uma fase. Não
System.PhaseName Um identificador baseado em cadeia de caracteres para um trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.PlanId Um identificador baseado em cadeia de caracteres para uma única execução de pipeline. Não
System.PullRequest.IsFork Se a solicitação de pull for de uma bifurcação do repositório, essa variável será definida como True. Caso contrário, ele será definido como False. Sim
System.PullRequest.PullRequestId A ID da solicitação de pull que causou esse build. Por exemplo: 17. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Não
System.PullRequest.PullRequestNumber O número da solicitação de pull que causou esse build. Essa variável é preenchida para solicitações de pull do GitHub que tenham uma ID de solicitação de pull diferente e um número de solicitação de pull. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.targetBranchName O nome do branch de destino para uma solicitação de pull. Essa variável pode ser usada em um pipeline para executar condicionalmente tarefas ou etapas com base no branch de destino da solicitação de pull. Por exemplo, talvez você queira disparar um conjunto diferente de testes ou ferramentas de análise de código, dependendo do branch no qual as alterações estão sendo mescladas. Não
System.PullRequest.SourceBranch O branch que está sendo revisado em uma solicitação de pull. Por exemplo: refs/heads/users/raisa/new-feature para o Azure Repos. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.SourceRepositoryURI A URL para o repositório que contém a solicitação de pull. Por exemplo: https://dev.azure.com/ouraccount/_git/OurProject. Não
System.PullRequest.TargetBranch O branch que é o destino de uma solicitação de pull. Por exemplo: refs/heads/main quando o repositório está no Azure Repos e main quando o repositório está no GitHub. Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.StageAttempt Defina como 1 na primeira vez em que esse estágio é tentado e incremente sempre que o estágio for repetido. Não
System.StageDisplayName O nome legível por humanos atribuído a um estágio. Não
System.StageName Um identificador baseado em cadeia de caracteres para um estágio, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.TeamFoundationCollectionUri O URI da coleção TFS ou da organização do Azure DevOps. Por exemplo: https://dev.azure.com/fabrikamfiber/.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.TeamProject O nome do projeto que contém esse build. Sim
System.TeamProjectId A ID do projeto ao qual este build pertence. Sim
System.TimelineId Um identificador baseado em cadeia de caracteres para os detalhes de execução e logs de uma única execução de pipeline. Não
TF_BUILD Defina como True se o script estiver sendo executado por uma tarefa de build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis de verificação (DevOps Services 2022)

Variável Descrição
Checks.StageAttempt Defina como 1 na primeira vez em que esse estágio é tentado e incremente sempre que o estágio for repetido.
Essa variável só pode ser usada em uma aprovação ou verificação de um ambiente. Por exemplo, você pode usar $(Checks.StageAttempt) em Invocar a verificação de API REST.
Adicione a tentativa de estágio como um parâmetro.

Variáveis do agente (DevOps Server 2020)

Observação

Você pode usar variáveis de agente como variáveis de ambiente em seus scripts e como parâmetros em suas tarefas de build. Você não pode usá-los para personalizar o número de build ou para aplicar um rótulo ou marca de controle de versão.

Variável Descrição
Agent.BuildDirectory O caminho local no agente onde todas as pastas de um determinado pipeline de build são criadas. Essa variável tem o mesmo valor que Pipeline.Workspace. Por exemplo: /home/vsts/work/1.
Agent.HomeDirectory O diretório no qual o agente está instalado. Isso contém o software do agente. Por exemplo: c:\agent.
Agent.Id A ID do agente.
Agent.JobName O nome do trabalho em execução. Isso geralmente será "Job" ou "__default", mas em cenários de várias configurações, será a configuração.
Agent.JobStatus O status do build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (parcialmente bem-sucedido)
  • Skipped (último trabalho)
A variável de ambiente deve ser referenciada como AGENT_JOBSTATUS. O agent.jobstatus mais antigo está disponível para compatibilidade com versões anteriores.
Agent.MachineName O nome do computador no qual o agente está instalado.
Agent.Name O nome do agente registrado no pool.

Se você estiver usando um agente auto-hospedado, esse nome será especificado por você. Consulte agentes.
Agent.OS O sistema operacional do host do agente. Os valores válidos são:
  • Windows_NT
  • Darwin
  • Linux
Se você estiver executando em um contêiner, o host e o contêiner do agente poderão estar executando sistemas operacionais diferentes.
Agent.OSArchitecture A arquitetura do processador do sistema operacional do host do agente. Os valores válidos são:
  • X86
  • X64
  • ARM processor
Agent.TempDirectory Uma pasta temporária que é limpa após cada trabalho de pipeline. Esse diretório é usado por tarefas como Tarefa da CLI do .NET Core para manter itens temporários, como resultados de teste antes de serem publicados.
Por exemplo: /home/vsts/work/_temp do Ubuntu.
Agent.ToolsDirectory O diretório usado por tarefas como o Instalador de Ferramentas do Node e a Versão do Python para alternar entre várias versões de uma ferramenta.

Essas tarefas adicionam ferramentas desse diretório a PATH para que as etapas de compilação subsequentes possam usá-las.

Saiba mais sobre como gerenciar esse diretório em um agente auto-hospedado.
Agent.WorkFolder O diretório de trabalho para esse agente. Por exemplo: c:\agent_work.

Observação: esse diretório não tem garantia de ser gravável por tarefas de pipeline (por exemplo, quando mapeado para um contêiner)

Variáveis de build (DevOps Server 2020)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
Build.ArtifactStagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildId A ID do registro para o build concluído. Não
Build.BuildNumber O nome do build concluído, também conhecido como o número de execução. Você pode especificar o que está incluído nesse valor.

Um uso típico dessa variável é torná-la parte do formato de rótulo, que você especifica na guia repositório.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BuildUri O URI do build. Por exemplo: vstfs:///Build/Build/1430.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.BinariesDirectory O caminho local no agente que você pode usar como uma pasta de saída para binários compilados.

Por padrão, novos pipelines de build não são configurados como limpos esse diretório. Você pode definir seu build para limpá-lo na guia Repositório.

Por exemplo: c:\agent_work\1\b.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.ContainerId A ID do contêiner para o artefato. Quando você carrega um artefato no seu pipeline, ele é adicionado a um contêiner específico nesse artefato específico. Não
Build.DefinitionName O nome do pipeline de build.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.DefinitionVersion A versão do pipeline de build. Sim
Build.QueuedBy Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.QueuedById Confira "Como as variáveis de identidade são definidas?". Sim
Build.Reason O evento que causou a execução do build.
  • Manual: um usuário colocava manualmente o build em fila.
  • IndividualCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC.
  • BatchedCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC e as alterações do Lote foram selecionadas.
  • Schedule: gatilho agendado.
  • ValidateShelveset: um usuário colocava manualmente em fila a compilação de um check-in particular do TFVC específico.
  • CheckInShelveset: gatilho de check-in restrito.
  • PullRequest: o build foi disparado por uma política de branch do Git que requer um build.
  • BuildCompletion: o build foi disparado por outro build
  • ResourceTrigger: o build foi disparado por um gatilho de recurso ou foi disparado por outro build.
Confira Gatilhos de pipeline de build, Melhorar a qualidade do código com políticas de branch.
Sim
Build.Repository.Clean O valor selecionado para Limpar nas configurações do repositório de origem.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.LocalPath O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Observação importante: se você fizer check-out apenas de um repositório Git, esse caminho será o caminho exato para o código.

Se você fizer check-out de vários repositórios, o comportamento será o seguinte (e poderá ser diferente do valor da variável Build.SourcesDirectory):
  • Se a etapa de check-out do repositório self (primário) não tiver nenhum caminho de check-out personalizado definido ou o caminho de check-out for o caminho $(Pipeline.Workspace)/s/&lt;RepoName&gt; padrão de check-out múltiplo para o repositório self, o valor dessa variável será revertido ao seu valor padrão, que é $(Pipeline.Workspace)/s.
  • Se a etapa de check-out do repositório self (primário) tiver um caminho de check-out personalizado definido (e não for seu caminho padrão de check-out múltiplo), essa variável conterá o caminho exato para o repositório self.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.ID O identificador único do repositório.

Isso não será alterado, ainda que o nome do repositório seja.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Name O nome do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Provider O tipo do repositório de gatilho.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Tfvc.Workspace Definido se o repositório é Controle de Versão do Team Foundation. O nome do workspace do TFVC usado pelo agente de build.

Por exemplo, se o Agent.BuildDirectory for c:\agent_work\12 e o Agent.Id for 8, o nome do workspace poderá ser: ws_12_8.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Uri A URL do repositório de gatilho. Por exemplo:
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.RequestedFor Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Sim
Build.RequestedForEmail Confira "Como as variáveis de identidade são definidas?". Sim
Build.RequestedForId Confira "Como as variáveis de identidade são definidas?". Sim
Build.SourceBranch O branch do repositório de gatilho para o qual o build foi colocado na fila. Alguns exemplos:
  • Branch do repositório Git: refs/heads/main
  • Solicitação de pull do repositório Git: refs/pull/1/merge
  • Branch do repositório TFVC: $/teamproject/main
  • Check-in restrito do repositório TFVC: Gated_2016-06-06_05.20.51.4369;username@live.com
  • Build do check-in particular do repositório TFVC: myshelveset;username@live.com
  • Quando o pipeline é disparado por uma marca: refs/tags/your-tag-name
Quando você usa essa variável no formato de número de build, as barras (/) são substituídos por sublinhados _).

Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourceBranchName O nome do branch no repositório de gatilho para o qual o build foi colocado na fila.
  • Branch do repositório Git, solicitação de pull ou marca: o último segmento de linha na referência. Por exemplo, refs/heads/main nesse valor é main. Em refs/heads/feature/tools, esse valor é tools. Em refs/tags/your-tag-name, esse valor é your-tag-name.
  • Branch do repositório TFVC: o último segmento de linha no caminho do servidor raiz para o workspace. Por exemplo, em $/teamproject/main, esse valor é main.
  • Check-in restrito ou build de check-in particular do repositório TFVC é o nome do check-in particular. Por exemplo, Gated_2016-06-06_05.20.51.4369;username@live.com ou myshelveset;username@live.com.
Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Sim
Build.SourcesDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados.

Observação importante: se você fizer check-out de apenas um repositório Git, esse caminho será o caminho exato para o código. Se você fizer check-out de vários repositórios, ele será revertido para seu valor padrão, que é $(Pipeline.Workspace)/s, mesmo que o repositório auto (primário) seja verificado em um caminho personalizado diferente do seu caminho padrão de vários check-outs $(Pipeline.Workspace)/s/<RepoName> (nesse aspecto, a variável difere do comportamento da variável Build.Repository.LocalPath).

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceVersion A alteração do controle de versão mais recente do repositório de gatilho incluído neste build.
Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
Build.SourceVersionMessage O comentário do commit ou do conjunto de alterações para o repositório de gatilho. Truncamos a mensagem para a primeira linha ou 200 caracteres, o que for menor.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Além disso, essa variável só está disponível no nível da etapa e não está disponível nos níveis de trabalho ou estágio (ou seja, a mensagem não é extraída até que o trabalho seja iniciado e o código seja verificado).

Observação: essa variável está disponível no TFS 2015.4.

Observação: a variável Build.SourceVersionMessage não funciona com pipelines de build clássicos nos repositórios do Bitbucket quando o Lote é alterado enquanto um build está em andamento estiver habilitado.
Não
Build.StagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.Repository.Git.SubmoduleCheckout O valor selecionado para Fazer check-out de submódulos na guia Repositório. Com o check-out de vários repositórios, esse valor acompanha a configuração do repositório de gatilho.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.SourceTfvcShelveset Definido se o repositório é Controle de Versão do Team Foundation.

Se você estiver executando um build fechado ou um build de conjunto de prateleiras, isso será definido como o nome do conjunto de prateleiras que você está criando.

Observação: essa variável produz um valor inválido para uso de build em um formato de número de build.
Não
Build.TriggeredBy.BuildId Se o build tiver sido disparado por outro build, essa variável será definida como a BuildID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.TriggeredBy.DefinitionId Se o build tiver sido disparado por outro build, essa variável será definida como a DefinitionID do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.TriggeredBy.DefinitionName Se o build tiver sido disparado por outro build, essa variável será definida como o nome do pipeline de build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.TriggeredBy.BuildNumber Se o build tiver sido disparado por outro build, essa variável será definida como o número do build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Build.TriggeredBy.ProjectID Se o build tiver sido disparado por outro build, essa variável será definida como a ID do projeto que contém o build de gatilho. Em pipelines clássicos, essa variável é disparada por um gatilho de conclusão do build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
Common.TestResultsDirectory O caminho local no agente em que os resultados do teste são criados. Por exemplo: c:\agent_work\1\TestResults.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis de pipeline (DevOps Server 2020)

Variável Descrição
Pipeline.Workspace Diretório do workspace para um pipeline específico. Essa variável tem o mesmo valor que Agent.BuildDirectory. Por exemplo, /home/vsts/work/1.

Variáveis do trabalho de implantação (DevOps Server 2020)

Essas variáveis têm escopo para um Trabalho de implantação específico e serão resolvidas somente no momento da execução do trabalho.

Variável Descrição
Environment.Name Nome do ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, smarthotel-dev.
Environment.Id ID do ambiente direcionado no trabalho de implantação. Por exemplo, 10.
Environment.ResourceName Nome do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação e registrar o histórico de implantação. Por exemplo, bookings que é um namespace do Kubernetes que foi adicionado como um recurso ao ambiente smarthotel-dev.
Environment.ResourceId ID do recurso específico no ambiente direcionado no trabalho de implantação para executar as etapas de implantação. Por exemplo, 4.

Variáveis do sistema (DevOps Server 2020)

Quando você usa uma variável em um modelo que não está marcado como disponível em modelos, a variável não será renderizada. A variável não será renderizada porque seu valor não está acessível no escopo do modelo.

Variável Descrição Disponível em modelos?
System.AccessToken Use o token OAuth para acessar a API REST.

Use System.AccessToken de scripts YAML.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.CollectionId O GUID da coleção TFS ou da organização do Azure DevOps Sim
System.CollectionUri Um URI de coleção do Team Foundation Server de cadeia de caracteres. Sim
System.DefaultWorkingDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não
System.DefinitionId A ID do pipeline de build. Sim
System.HostType Defina como build se o pipeline for um build. Para uma versão, os valores são deployment para um trabalho de grupo de implantação, gates durante a avaliação de portões e release para outros trabalhos (com e sem agente). Sim
System.JobAttempt Defina como 1 na primeira vez em que esse trabalho é tentado e incremente sempre que o trabalho for repetido. Não
System.JobDisplayName O nome legível por humanos atribuído a um trabalho. Não
System.JobId Um identificador exclusivo para uma única tentativa de um único trabalho. O valor é exclusivo para o pipeline atual. Não
System.JobName O nome do trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.PhaseAttempt Defina como 1 na primeira vez em que essa fase é tentada e incremente sempre que o trabalho for repetido.

Observação: "Fase" é um conceito redundante que representa o tempo de design de um trabalho (enquanto o trabalho era a versão de runtime de uma fase). Removemos principalmente o conceito de "fase" do Azure Pipelines. Os trabalhos de matriz e de configurações múltiplas são o único lugar em que "fase" ainda é diferente de "trabalho". Uma fase pode instanciar vários trabalhos que diferem apenas nas suas entradas.
Não
System.PhaseDisplayName O nome legível por humanos atribuído a uma fase. Não
System.PhaseName Um identificador baseado em cadeia de caracteres para um trabalho, normalmente usado para expressar dependências e acessar variáveis de saída. Não
System.StageAttempt Defina como 1 na primeira vez em que esse estágio é tentado e incremente sempre que o trabalho for repetido. Não
System.StageDisplayName O nome legível por humanos atribuído a um estágio. Não
System.StageName Um identificador baseado em cadeia de caracteres para um estágio, normalmente usado para expressar dependências e acessar variáveis de saída. Sim
System.PullRequest.IsFork Se a solicitação de pull for de uma bifurcação do repositório, essa variável será definida como True. Caso contrário, ele será definido como False. Sim
System.PullRequest.PullRequestId A ID da solicitação de pull que causou esse build. Por exemplo: 17. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Não
System.PullRequest.PullRequestNumber O número da solicitação de pull que causou esse build. Essa variável é preenchida para solicitações de pull do GitHub que têm uma ID de solicitação de pull e um número de solicitação de pull diferentes. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.targetBranchName O nome do branch de destino para uma solicitação de pull. Essa variável pode ser usada em um pipeline para executar condicionalmente tarefas ou etapas com base no branch de destino da solicitação de pull. Por exemplo, talvez você queira disparar um conjunto diferente de testes ou ferramentas de análise de código, dependendo do branch no qual as alterações estão sendo mescladas. Não
System.PullRequest.SourceBranch O branch que está sendo revisado em uma solicitação de pull. Por exemplo: refs/heads/users/raisa/new-feature. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.PullRequest.SourceCommitId O branch que está sendo revisado em uma solicitação de pull. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch). Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch.
System.PullRequest.SourceRepositoryURI A URL para o repositório que contém a solicitação de pull. Por exemplo: https://dev.azure.com/ouraccount/_git/OurProject. Não
System.PullRequest.TargetBranch O branch que é o destino de uma solicitação de pull. Por exemplo: refs/heads/main quando o repositório está no Azure Repos e main quando o repositório está no GitHub. Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch. Essa variável só estará disponível em um pipeline YAML se a PR for afetada por uma política de branch. Não
System.TeamFoundationCollectionUri O URI da coleção do Team Foundation. Por exemplo: https://dev.azure.com/fabrikamfiber/.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Sim
System.TeamProject O nome do projeto que contém esse build. Sim
System.TeamProjectId A ID do projeto ao qual este build pertence. Sim
TF_BUILD Defina como True se o script estiver sendo executado por uma tarefa de build.

Essa variável tem escopo de agente e pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Não

Variáveis do agente (DevOps Server 2019)

Observação

Você pode usar variáveis de agente como variáveis de ambiente em seus scripts e como parâmetros em suas tarefas de build. Você não pode usá-los para personalizar o número de build ou para aplicar um rótulo ou marca de controle de versão.

Variável Descrição
Agent.BuildDirectory O caminho local no agente onde todas as pastas de um determinado pipeline de build são criadas. Por exemplo: c:\agent_work\1.
Agent.HomeDirectory O diretório no qual o agente está instalado. Isso contém o software do agente. Por exemplo: c:\agent.
Agent.Id A ID do agente.
Agent.JobName O nome do trabalho em execução. Isso geralmente será "Job" ou "__default", mas em cenários de várias configurações, será a configuração.
Agent.JobStatus O status do build.
  • Canceled
  • Failed
  • Succeeded
  • SucceededWithIssues (parcialmente bem-sucedido)
  • Skipped (último trabalho)
A variável de ambiente deve ser referenciada como AGENT_JOBSTATUS. O agent.jobstatus mais antigo está disponível para compatibilidade com versões anteriores.
Agent.MachineName O nome do computador no qual o agente está instalado.
Agent.Name O nome do agente registrado no pool.

Se você estiver usando um agente auto-hospedado, esse nome será definido por você. Consulte agentes.
Agent.OS O sistema operacional do host do agente. Os valores válidos são:
  • Windows_NT
  • Darwin
  • Linux
Se você estiver executando em um contêiner, o host e o contêiner do agente poderão estar executando sistemas operacionais diferentes.
Agent.OSArchitecture A arquitetura do processador do sistema operacional do host do agente. Os valores válidos são:
  • X86
  • X64
  • ARM processor
Agent.TempDirectory Uma pasta temporária que é limpa após cada trabalho de pipeline. Esse diretório é usado por tarefas como Tarefa da CLI do .NET Core para manter itens temporários, como resultados de teste antes de serem publicados.
Agent.ToolsDirectory O diretório usado por tarefas como o Instalador de Ferramentas do Node e a Versão do Python para alternar entre várias versões de uma ferramenta.

Essas tarefas adicionam ferramentas desse diretório a PATH para que as etapas de compilação subsequentes possam usá-las.

Saiba mais sobre como gerenciar esse diretório em um agente auto-hospedado.
Agent.WorkFolder O diretório de trabalho para esse agente. Por exemplo: c:\agent_work.

Esse diretório não tem garantia de ser gravável por tarefas de pipeline (por exemplo, quando mapeado para um contêiner).

Variáveis de build (DevOps Server 2019)

Variável Descrição
Build.ArtifactStagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.BuildId A ID do registro para o build concluído.
Build.BuildNumber O nome do build concluído. Você pode especificar o formato de número de build que gera esse valor nas opções de pipeline.

Um uso típico dessa variável é torná-la parte do formato de rótulo, que você especifica na guia repositório.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.BuildUri O URI do build. Por exemplo: vstfs:///Build/Build/1430.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.BinariesDirectory O caminho local no agente que você pode usar como uma pasta de saída para binários compilados.

Por padrão, novos pipelines de build não são configurados como limpos esse diretório. Você pode definir seu build para limpá-lo na guia Repositório.

Por exemplo: c:\agent_work\1\b.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.DefinitionName O nome do pipeline de build.

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Build.DefinitionVersion A versão do pipeline de build.
Build.QueuedBy Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Build.QueuedById Confira "Como as variáveis de identidade são definidas?".
Build.Reason O evento que causou a execução do build.
  • Manual: um usuário colocava manualmente o build em fila.
  • IndividualCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC.
  • BatchedCI: CI (integração contínua) disparada por um push do Git ou um check-in do TFVC e as alterações do Lote foram selecionadas.
  • Schedule: gatilho agendado.
  • ValidateShelveset: um usuário colocava manualmente em fila a compilação de um check-in particular do TFVC específico.
  • CheckInShelveset: gatilho de check-in restrito.
  • PullRequest: o build foi disparado por uma política de branch do Git que requer um build.
  • BuildCompletion: o build foi disparado por outro build.
Confira Gatilhos de pipeline de build, Melhorar a qualidade do código com políticas de branch.
Build.Repository.Clean O valor selecionado para Limpar nas configurações do repositório de origem.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.Repository.LocalPath O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Essa variável é sinônimo de Build.SourcesDirectory.
Build.Repository.Name O nome do repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.Repository.Provider O tipo de repositório selecionado.
Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.Repository.Tfvc.Workspace Definido se o repositório é Controle de Versão do Team Foundation. O nome do workspace do TFVC usado pelo agente de build.

Por exemplo, se o Agent.BuildDirectory for c:\agent_work\12 e o Agent.Id for 8, o nome do workspace poderá ser: ws_12_8.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.Repository.Uri A URL do repositório. Por exemplo:
Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.RequestedFor Confira "Como as variáveis de identidade são definidas?".

Observação: esse valor pode conter espaço em branco ou outros caracteres de rótulo inválidos. Nesses casos, o formato do rótulo falhará.
Build.RequestedForEmail Confira "Como as variáveis de identidade são definidas?".
Build.RequestedForId Confira "Como as variáveis de identidade são definidas?".
Build.SourceBranch O branch para o qual o build foi colocado na fila. Alguns exemplos:
  • Branch do repositório Git: refs/heads/main
  • Solicitação de pull do repositório Git: refs/pull/1/merge
  • Branch do repositório TFVC: $/teamproject/main
  • Check-in restrito do repositório TFVC: Gated_2016-06-06_05.20.51.4369;username@live.com
  • Build do check-in particular do repositório TFVC: myshelveset;username@live.com
Quando você usa essa variável no formato de número de build, as barras (/) são substituídos por sublinhados (_).

Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Build.SourceBranchName O nome do branch para o qual o build foi colocado na fila.
  • Branch do repositório Git, solicitação de pull ou marca: o último segmento de linha na referência. Por exemplo, refs/heads/main nesse valor é main. Em refs/heads/feature/tools, esse valor é tools. Em refs/tags/your-tag-name, esse valor é your-tag-name.
  • Branch do repositório TFVC: o último segmento de linha no caminho do servidor raiz para o workspace. Por exemplo, em $/teamproject/main, esse valor é main.
  • Check-in restrito ou build de check-in particular do repositório TFVC é o nome do check-in particular. Por exemplo, Gated_2016-06-06_05.20.51.4369;username@live.com ou myshelveset;username@live.com.
Observação: no TFVC, se você estiver executando um build de check-in fechado ou criando manualmente um conjunto de prateleiras, não poderá usar essa variável no formato de número de build.
Build.SourcesDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s.

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Essa variável é sinônimo de Build.Repository.LocalPath.
Build.SourceVersion A alteração no controle de versão mais recente incluída neste build.
Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.SourceVersionMessage O comentário do commit ou do conjunto de alterações. Truncamos a mensagem para a primeira linha ou 200 caracteres, o que for menor.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Observação: essa variável está disponível no TFS 2015.4.

Observação: a variável Build.SourceVersionMessage não funciona com pipelines de build clássicos nos repositórios do Bitbucket quando o Lote é alterado enquanto um build está em andamento estiver habilitado.
Build.StagingDirectory O caminho local no agente para o qual todos os artefatos são copiados antes de serem enviados por push para seu destino. Por exemplo: c:\agent_work\1\a.

Uma maneira típica de usar essa pasta é publicar seus artefatos de build com as tarefas Copiar arquivos e Publicar artefatos de build.

Observação: Build.ArtifactStagingDirectory e Build.StagingDirectory são intercambiáveis. Esse diretório é limpo antes de cada nova compilação, para que você não precise limpá-lo por conta própria.

Confira Artefatos no Azure Pipelines.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.Repository.Git.SubmoduleCheckout O valor que você selecionou para Fazer check-out de submódulos na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.SourceTfvcShelveset Definido se o repositório é Controle de Versão do Team Foundation.

Se você estiver executando um build fechado ou um build de conjunto de prateleiras, isso será definido como o nome do conjunto de prateleiras que você está criando.

Observação: essa variável produz um valor inválido para uso de build em um formato de número de build.
Build.TriggeredBy.BuildId Se o build tiver sido disparado por outro build, essa variável será definida como a BuildID do build de gatilho.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.TriggeredBy.DefinitionId Se o build tiver sido disparado por outro build, essa variável será definida como a DefinitionID do build de gatilho.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.TriggeredBy.DefinitionName Se o build tiver sido disparado por outro build, essa variável será definida como o nome do pipeline de build de gatilho.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.TriggeredBy.BuildNumber Se o build tiver sido disparado por outro build, essa variável será definida como o número do build de gatilho.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Build.TriggeredBy.ProjectID Se o build tiver sido disparado por outro build, essa variável será definida como a ID do projeto que contém o build de gatilho.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
Common.TestResultsDirectory O caminho local no agente em que os resultados do teste são criados. Por exemplo: c:\agent_work\1\TestResults.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Variáveis do sistema (DevOps Server 2019)

Exemplo de script do PowerShell: acessar a API REST

Variável Descrição
System.AccessToken Use o token OAuth para acessar a API REST.

Use System.AccessToken de scripts YAML.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
System.CollectionId O GUID da coleção TFS ou da organização do Azure DevOps
System.DefaultWorkingDirectory O caminho local dele no agente em que os arquivos de código-fonte são baixados. Por exemplo: c:\agent_work\1\s

Por padrão, novos pipelines de build atualizam apenas os arquivos alterados. Você pode modificar como os arquivos são baixados na guia Repositório.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
System.DefinitionId A ID do pipeline de build.
System.HostType Defina como build se o pipeline for um build. Para uma versão, os valores são deployment para um trabalho do grupo de implantação e release para um trabalho do agente.
System.PullRequest.IsFork Se a solicitação de pull for de uma bifurcação do repositório, essa variável será definida como True. Caso contrário, ele será definido como False.
System.PullRequest.PullRequestId A ID da solicitação de pull que causou esse build. Por exemplo: 17. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch).
System.PullRequest.PullRequestNumber O número da solicitação de pull que causou esse build. Essa variável é preenchida para solicitações de pull do GitHub que têm uma ID de solicitação de pull e um número de solicitação de pull diferentes.
System.PullRequest.SourceBranch O branch que está sendo revisado em uma solicitação de pull. Por exemplo: refs/heads/users/raisa/new-feature. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch).
System.PullRequest.SourceCommitId O branch que está sendo revisado em uma solicitação de pull. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch).
System.PullRequest.SourceRepositoryURI A URL para o repositório que contém a solicitação de pull. Por exemplo: https://dev.azure.com/ouraccount/_git/OurProject. (Essa variável será inicializada somente se o build for executado devido a uma PR do Git do Azure Repos afetada por uma política de ramificação). Ele não é inicializado para PRs do GitHub.)
System.PullRequest.TargetBranch O branch que é o destino de uma solicitação de pull. Por exemplo: refs/heads/main. Essa variável será inicializada somente se o build for executado devido a uma PR do Git afetada por uma política de branch.
System.TeamFoundationCollectionUri O URI da coleção do Team Foundation. Por exemplo: https://dev.azure.com/fabrikamfiber/.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.
System.TeamProject O nome do projeto que contém esse build.
System.TeamProjectId A ID do projeto ao qual este build pertence.
TF_BUILD Defina como True se o script estiver sendo executado por uma tarefa de build.

Essa variável tem escopo de agente. Ela pode ser usada como uma variável de ambiente em um script e como um parâmetro em uma tarefa de build, mas não como parte do número de build ou como uma marca de controle de versão.

Como as variáveis de identidade são definidas?

O valor depende do que causou o build e são específicos para repositórios do Azure Repos.

Se o build for disparado... Os valores Build.QueuedBy e Build.QueuedById são baseados... Os valores Build.RequestedFor e Build.RequestedForId são baseados...
No Git ou TFVC pelos Gatilhos de integração contínua (CI) A identidade do sistema, por exemplo: [DefaultCollection]\Project Collection Service Accounts A pessoa que efetuou push ou fez check-in das alterações.
No Git ou por um build de política de branch. A identidade do sistema, por exemplo: [DefaultCollection]\Project Collection Service Accounts A pessoa que fez check-in as alterações.
No TFVC por um gatilho de check-in restrito A pessoa que fez check-in as alterações. A pessoa que fez check-in as alterações.
No Git ou TFVC pelos gatilhos agendados A identidade do sistema, por exemplo: [DefaultCollection]\Project Collection Service Accounts A identidade do sistema, por exemplo: [DefaultCollection]\Project Collection Service Accounts
Porque você clicou no botão Colocar build na fila Você Você