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.

YAML

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.

Clássico

Você pode permitir que scripts e tarefas acessem System.AccessToken no nível do trabalho.

1. Navegue até o trabalho

2. Em Opções adicionais, marcar a caixa Permitir que scripts acessem o token OAuth.

A marcação dessa caixa também deixa a credencial definida no Git para que você possa executar pushes e pulls em seus scripts.

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.

   

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. TfsGit: repositório Git do TFS TfsVersionControl: Controle de Versão do Team Foundation Git: repositório Git hospedado em um servidor externo GitHub Svn: Subversion 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: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: 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.	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. Git: a ID de confirmação. TFVC: o conjunto de alterações. 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 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)

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.

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ê