Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
As variáveis fornecem uma forma conveniente de incluir dados-chave em várias partes do pipeline. A utilização mais comum das variáveis é definir um valor que pode usar ao longo do seu pipeline. Todas as variáveis são cadeias mutáveis. O valor de uma variável pode variar de execução para execução ou de trabalho para trabalho no seu pipeline.
Quando você define a mesma variável em vários locais com o mesmo nome, a variável com escopo mais local tem precedência. Assim, uma variável definida no nível do trabalho pode substituir uma variável definida no nível do estágio. Uma variável definida no nível do estágio substitui uma variável definida no nível raiz do pipeline. Uma variável definida no nível raiz do pipeline substitui uma variável definida nas configurações da interface de utilizador do pipeline. Para saber mais sobre como trabalhar com variáveis definidas ao nível do trabalho, estágio e raiz, consulte Âmbito de variáveis.
Pode usar variáveis com expressões para atribuir valores condicionalmente e personalizar pipelines ainda mais.
As variáveis diferem dos parâmetros de tempo de execução. Os parâmetros de runtime são escritos e estão disponíveis durante a análise de modelos.
Variáveis definidas pelo usuário
Quando defines uma variável, usa sintaxes diferentes (macro, expressão de template ou runtime). A sintaxe que escolhes determina onde na pipeline a variável é renderizada.
Nos pipelines YAML, defina variáveis nos níveis de raiz, estágio e tarefa. Você também pode especificar variáveis fora de um pipeline YAML na interface do usuário. Quando defines uma variável na interface, podes encriptá-la e defini-la como secreta.
As variáveis definidas pelo usuário podem ser definidas como somente leitura. Há restrições de nomenclatura para variáveis (exemplo: você não pode usar secret no início de um nome de variável).
Pode usar um grupo de variáveis para disponibilizar variáveis em vários pipelines.
Para definir variáveis num ficheiro para uso em múltiplos pipelines, use templates.
Variáveis de várias linhas definidas pelo usuário
O Azure DevOps suporta variáveis multi-linha, mas existem algumas limitações.
Componentes downstream, como tarefas de pipeline, podem não manipular os valores das variáveis corretamente.
O Azure DevOps não altera os valores das variáveis definidas pelo utilizador. Precisas de formatar corretamente os valores das variáveis antes de os passar como variáveis multilinha. Ao formatar sua variável, evite caracteres especiais, não use nomes restritos e certifique-se de usar um formato de terminação de linha que funcione para o sistema operacional do seu agente.
As variáveis de várias linhas se comportam de forma diferente dependendo do sistema operacional. Para evitar este problema, certifique-se de formatar corretamente variáveis multi-linha para o sistema operativo de destino.
O Azure DevOps nunca altera os valores das variáveis, mesmo que forneça formatação não suportada.
Variáveis do sistema
Para além das variáveis definidas pelo utilizador, o Azure Pipelines tem variáveis de sistema com valores pré-definidos. Por exemplo, a variável predefinida Build.BuildId fornece a ID de cada compilação e pode ser usada para identificar diferentes execuções de pipeline. Você pode usar a Build.BuildId variável em scripts ou tarefas quando precisar de um valor exclusivo.
Se estiver a usar YAML ou build pipelines clássicos, consulte variáveis predefinidas para uma lista abrangente de variáveis do sistema.
Se estiver a usar pipelines de lançamento clássico, consulte variáveis de lançamento.
Quando executas o pipeline, as variáveis do sistema definem o seu valor atual. Algumas variáveis são definidas automaticamente. Como autor ou utilizador final de pipeline, pode alterar o valor de uma variável do sistema antes de o pipeline ser executado.
As variáveis de sistema são somente leitura.
Variáveis de ambiente
As variáveis de ambiente são específicas do sistema operacional que você está usando. Você injeta-os num fluxo de trabalho de maneiras específicas para cada plataforma. O formato corresponde a como as variáveis de ambiente são formatadas para sua plataforma de script específica.
Em sistemas UNIX (macOS e Linux), as variáveis de ambiente têm o formato $NAME. No Windows, o formato é %NAME% para lote e $env:NAME no PowerShell.
As variáveis definidas pelo sistema e pelo usuário (exceto variáveis secretas) também são injetadas como variáveis de ambiente para sua plataforma. Quando as variáveis se convertem em variáveis de ambiente, os nomes das variáveis tornam-se maiúsculas e os períodos transformam-se em sublinhados. Por exemplo, o nome any.variable da variável torna-se o nome $ANY_VARIABLEda variável .
Há restrições de nomenclatura de variáveis para variáveis de ambiente (exemplo: você não pode usar secret no início de um nome de variável).
Restrições de nomenclatura das variáveis
As variáveis definidas pelo usuário e de ambiente podem consistir em letras, .números e _ caracteres. Não use prefixos variáveis reservados pelo sistema. Estes prefixos são: endpoint, input, secret, path, e securefile. Qualquer variável que comece com uma dessas cadeias de caracteres (independentemente da capitalização) não estará disponível para suas tarefas e scripts. Não use espaços em variáveis. Para restrições adicionais, consulte restrições de nomenclatura do Azure Pipelines.
Compreender a sintaxe das variáveis
O Azure Pipelines suporta três formas diferentes de referenciar variáveis: macro, expressão template e expressão em tempo de execução. Podes usar cada sintaxe para um propósito diferente e cada uma tem algumas limitações.
Em um pipeline, as variáveis de expressão de modelo (${{ variables.var }}) são processadas em tempo de compilação, antes do início do tempo de execução. As variáveis de sintaxe de macro ($(var)) são processadas durante o tempo de execução antes da execução de uma tarefa. As expressões de tempo de execução ($[variables.var]) também são processadas durante o tempo de execução, mas destinam-se a ser usadas com condições e expressões. Quando utiliza uma expressão de runtime, deve ocupar todo o lado direito de uma definição.
Neste exemplo, você pode ver que a expressão de modelo ainda tem o valor inicial da variável depois que a variável é atualizada. O valor da variável de sintaxe de macro é atualizado. O valor da expressão template não muda porque o pipeline processa todas as variáveis da expressão template em tempo de compilação antes da execução das tarefas. Por outro lado, as variáveis de sintaxe de macro são avaliadas antes de cada tarefa ser executada.
variables:
- name: one
value: initialValue
steps:
- script: |
echo ${{ variables.one }} # outputs initialValue
echo $(one)
displayName: First variable pass
- bash: echo "##vso[task.setvariable variable=one]secondValue"
displayName: Set new variable value
- script: |
echo ${{ variables.one }} # outputs initialValue
echo $(one) # outputs secondValue
displayName: Second variable pass
Variáveis de sintaxe de macro
A maioria dos exemplos de documentação usa sintaxe de macro ($(var)). Use a sintaxe de macros para interpolar os valores das variáveis em entradas de tarefa e em outras variáveis.
O sistema processa variáveis com sintaxe macro antes de uma tarefa ser executada durante a execução. O tempo de execução acontece após a expansão do modelo. Quando o sistema encontra uma expressão de macro, ele substitui a expressão pelo conteúdo da variável. Se não houver variável com esse nome, a expressão macro não muda. Por exemplo, se $(var) não puder ser substituído, permanece como $(var).
As variáveis de sintaxe macro mantêm-se inalteradas quando não têm valor porque um valor vazio, como $() isso, pode significar algo para a tarefa que está a executar e o agente não deve assumir que quer que esse valor seja substituído. Por exemplo, se utilizar $(foo) para referenciar a variável foo numa tarefa Bash, substituir as expressões $() na entrada da tarefa pode comprometer os seus scripts Bash.
As variáveis macro só expandem quando são usadas para um valor, não como palavra-chave. Os valores aparecem no lado direito de uma definição de pipeline. O seguinte é válido: key: $(value). O seguinte não é válido: $(key): value. As variáveis de macro não são expandidas quando usadas para exibir um nome de tarefa em linha. Em vez disso, você deve usar a displayName propriedade.
Nota
O sistema apenas expande variáveis de sintaxe macro para entradas de tarefas dentro de stages, jobs e steps.
Não os expande em palavras-chave de pipeline que se resolvem em tempo de compilação, como resources, trigger, ou o valor de referência do repositório da etapa checkout (por exemplo, checkout: git://MyProject/MyRepo@$(var) não funciona).
Para parametrizar estes valores, use expressões modelo (${{ }}) ou parâmetros de tempo de execução em vez disso.
Este exemplo usa sintaxe de macro com Bash, PowerShell e uma tarefa de script. A sintaxe para chamar uma variável usando macro é a mesma para as três.
variables:
- name: projectName
value: contoso
steps:
- bash: echo $(projectName)
- powershell: echo $(projectName)
- script: echo $(projectName)
Sintaxe da expressão de template
Use a sintaxe da expressão template para expandir tanto parâmetros template como variáveis (${{ variables.var }}). O sistema processa variáveis modelo em tempo de compilação e substitui-as antes do início do runtime. Use expressões template para reutilizar partes do YAML como templates.
As variáveis de modelo coalescem silenciosamente em cadeias de caracteres vazias quando um valor de substituição não é encontrado. As expressões de modelo, ao contrário das expressões de macro e tempo de execução, podem aparecer como teclas (lado esquerdo) ou valores (lado direito). O seguinte é válido: ${{ variables.key }} : ${{ variables.value }}.
Sintaxe de expressões em tempo de execução
Use a sintaxe de expressões em tempo de execução para variáveis que se expandem em tempo de execução ($[variables.var]). As variáveis de expressão de tempo de execução se aglutinam silenciosamente em cadeias de caracteres vazias quando um valor de substituição não é encontrado. Use expressões em tempo de execução em condições de trabalho para suportar a execução condicional de tarefas ou fases inteiras.
As variáveis de expressão em tempo de execução só expandem quando são usadas para um valor, não como palavra-chave. Os valores aparecem no lado direito de uma definição de pipeline. O seguinte é válido: key: $[variables.value]. O seguinte não é válido: $[variables.key]: value. A expressão em tempo de execução deve ocupar todo o lado direito de um par chave-valor. Por exemplo, key: $[variables.value] é válido, mas key: $[variables.value] foo não é.
| Sintaxe | Exemplo | Quando é processado? | Onde é que ela se expande numa definição de pipeline? | Como renderiza quando não é encontrado? |
|---|---|---|---|---|
| macro | $(var) |
tempo de execução antes da execução de uma tarefa | valor (lado direito) | impressões $(var) |
| expressão de modelo | ${{ variables.var }} |
tempo de compilação | chave ou valor (lado esquerdo ou lado direito) | cadeia vazia |
| expressão de execução | $[variables.var] |
runtime | valor (lado direito) | cadeia vazia |
Que sintaxe devo usar?
Use a sintaxe macro se estiver a fornecer uma string segura ou uma entrada predefinida para uma tarefa.
Escolha uma expressão de tempo de execução se estiver a trabalhar com condições e [expressões](expressions.md). No entanto, não use uma expressão de tempo de execução se não quiser que sua variável vazia seja impressa (exemplo: $[variables.var]). Por exemplo, se tiveres lógica condicional que depende de uma variável ter um valor específico ou nenhum, usa uma expressão macro.
Normalmente, uma variável modelo é o padrão a usar. Ao utilizar variáveis de modelo, o seu pipeline injeta completamente o valor da variável no seu pipeline durante a compilação. Esta injeção é benéfica quando se tenta depurar pipelines. Você pode baixar os arquivos de log e avaliar o valor completamente expandido que está a ser substituído. Como a variável é substituída, não utilize a sintaxe de modelo para valores sensíveis.
Usar a IA para identificar problemas de sintaxe variável
Este exemplo de prompt para o Copilot Chat identifica que tipos de variáveis são usados num pipeline e quando as variáveis se resolvem. Realce o seu código YAML e depois insira o seguinte prompt do Copilot Chat.
What types of Azure DevOps variables are used in this YAML pipeline? Give specific examples.
When does each variable process in the pipeline?
How will each variable render when not found?
What stages and jobs will the variables be available for?
Personalize seu prompt para adicionar detalhes conforme necessário.
O copiloto é alimentado por IA, por isso surpresas e erros são possíveis. Para mais informações, consulte Copilot FAQs.
Definir variáveis no pipeline
No caso mais comum, defina as variáveis e utilize-as dentro do ficheiro YAML. Esta abordagem permite-lhe acompanhar alterações à variável no seu sistema de controlo de versões. Você também pode definir variáveis na interface do usuário de configurações de pipeline (consulte a guia Clássico) e fazer referência a elas em seu YAML.
O exemplo seguinte mostra como definir duas variáveis, configuration e platform, e usá-las mais tarde em etapas. Para usar uma variável em uma instrução YAML, envolva-a em $(). Não podes usar variáveis para definir a repository numa instrução YAML.
# Set variables once
variables:
configuration: debug
platform: x64
steps:
# Use them once
- task: MSBuild@1
inputs:
solution: solution1.sln
configuration: $(configuration) # Use the variable
platform: $(platform)
# Use them again
- task: MSBuild@1
inputs:
solution: solution2.sln
configuration: $(configuration) # Use the variable
platform: $(platform)
Escopos variáveis
No ficheiro YAML, defina uma variável em vários escopos:
- No nível raiz, para disponibilizá-lo para todas as tarefas no ciclo de trabalho.
- Ao nível do estágio, torná-lo disponível apenas para um estágio específico.
- Ao nível do trabalho, de forma a disponibilizá-lo apenas para um trabalho específico.
Quando você define uma variável na parte superior de um YAML, a variável está disponível para todos os trabalhos e estágios no pipeline e é uma variável global. As variáveis globais definidas em um YAML não são visíveis na interface do usuário de configurações do pipeline.
As variáveis no nível do trabalho substituem as variáveis no nível raiz e no nível do estágio. As variáveis no nível do estágio substituem as variáveis no nível raiz.
variables:
global_variable: value # this is available to all jobs
jobs:
- job: job1
pool:
vmImage: 'ubuntu-latest'
variables:
job_variable1: value1 # this is only available in job1
steps:
- bash: echo $(global_variable)
- bash: echo $(job_variable1)
- bash: echo $JOB_VARIABLE1 # variables are available in the script environment too
- job: job2
pool:
vmImage: 'ubuntu-latest'
variables:
job_variable2: value2 # this is only available in job2
steps:
- bash: echo $(global_variable)
- bash: echo $(job_variable2)
- bash: echo $GLOBAL_VARIABLE
A saída de ambos os trabalhos tem este aspecto:
# job1
value
value1
value1
# job2
value
value2
value
Especificar variáveis
Nos exemplos anteriores, a variables palavra-chave é seguida por uma lista de pares chave-valor.
As chaves são os nomes das variáveis e os valores são os valores das variáveis.
Outra sintaxe é útil quando quiseres usar templates para variáveis ou grupos de variáveis.
Ao usar templates, pode definir variáveis num ficheiro YAML e incluí-las noutro ficheiro YAML.
Os grupos de variáveis são um conjunto de variáveis que podes usar em vários pipelines. Ao usar grupos de variáveis, pode gerir e organizar variáveis comuns a várias fases num só local.
Use esta sintaxe para modelos de variáveis e grupos de variáveis no nível raiz de um pipeline.
Nessa sintaxe alternativa, a variables palavra-chave usa uma lista de especificadores de variáveis.
Os especificadores de variáveis são name para uma variável regular, group para um grupo de variáveis e template para incluir um modelo de variável.
O exemplo a seguir demonstra todos os três.
variables:
# a regular variable
- name: myvariable
value: myvalue
# a variable group
- group: myvariablegroup
# a reference to a variable template
- template: myvariabletemplate.yml
Para saber mais, consulte Reutilização de variáveis com modelos.
Aceder a variáveis através do ambiente
Observe que as variáveis também são disponibilizadas para scripts por meio de variáveis de ambiente. A sintaxe para usar essas variáveis de ambiente depende da linguagem de script.
O nome está em maiúsculas e o . é substituído pelo _. Isso é inserido automaticamente no ambiente do processo. Seguem-se alguns exemplos:
- Script em lote:
%VARIABLE_NAME% - Script do PowerShell:
$env:VARIABLE_NAME - Script de Bash:
$VARIABLE_NAME
Importante
As variáveis predefinidas que contêm caminhos de arquivo são convertidas para o estilo apropriado (estilo do Windows C:\foo\ versus estilo Unix /foo/) com base no tipo de host do agente e no tipo de shell. Caso esteja a executar tarefas de script bash no Windows, deverá usar o método de variável de ambiente para aceder a essas variáveis em vez do método de variável de pipeline para garantir que tem a estilização de caminho de ficheiro correta.
Definir variáveis de segredos
Gorjeta
As variáveis secretas não são exportadas automaticamente como variáveis de ambiente. Para usar variáveis secretas em seus scripts, mapeie-as explicitamente para variáveis de ambiente. Para obter mais informações, consulte Definir variáveis secretas.
Não defina variáveis secretas em seu arquivo YAML. Os sistemas operacionais geralmente registram comandos para os processos que eles executam, e você não gostaria que o log incluísse um segredo que você passou como entrada. Use o ambiente do script ou mapeie a variável dentro do bloco variables para passar segredos para a sua pipeline.
Nota
O Azure Pipelines esforça-se por mascarar segredos ao emitir dados para logs de pipeline, por isso podes ver variáveis e dados adicionais mascarados na saída e logs que não estão definidos como segredos.
Você precisa definir variáveis secretas na interface de configurações do pipeline para o seu pipeline. Essas variáveis têm como escopo o pipeline onde estão definidas. Você também pode definir variáveis secretas em grupos de variáveis.
Para definir segredos na interface Web, siga estes passos:
- Vai à página Pipelines, seleciona o pipeline apropriado e depois seleciona Edit.
- Encontre as variáveis para este pipeline.
- Adicione ou atualize a variável.
- Selecione a opção Manter esse valor secreto para armazenar a variável de forma criptografada.
- Guarde o pipeline.
As variáveis secretas são encriptadas em repouso com uma chave RSA de 2048 bits. Os segredos estão disponíveis no agente para utilização em tarefas e scripts. Tem cuidado com quem tem acesso para alterar o teu pipeline.
Importante
Fazemos um esforço para mascarar segredos que não aparecem na saída do Azure Pipelines, mas ainda assim é necessário tomar precauções. Nunca exiba segredos como saída. Alguns sistemas operacionais registram argumentos de linha de comando. Nunca passe segredos na linha de comando. Em vez disso, sugerimos que você mapeie seus segredos em variáveis de ambiente.
Nunca mascaramos subsequências de segredos. Se, por exemplo, "abc123" for definido como um segredo, "abc" não fica mascarado nos registos. Isso é para evitar mascarar segredos em um nível muito granular, tornando os logs ilegíveis. Por esta razão, os segredos não devem conter dados estruturados. Se, por exemplo, "{ "foo": "bar" }" for definido como um segredo, "bar" não será ocultado nos registos.
Ao contrário de uma variável normal, eles não são automaticamente descriptografados em variáveis de ambiente para scripts. Você precisa mapear explicitamente variáveis secretas.
O exemplo a seguir mostra como mapear e usar uma variável secreta chamada mySecret em scripts PowerShell e Bash. Duas variáveis globais são definidas.
GLOBAL_MYSECRET é atribuído o valor de uma variável mySecretsecreta e GLOBAL_MY_MAPPED_ENV_VAR é atribuído o valor de uma variável nonSecretVariablenão secreta . Ao contrário de uma variável de pipeline normal, não há nenhuma variável de ambiente chamada MYSECRET.
A tarefa do PowerShell executa um script para imprimir as variáveis.
-
$(mySecret): Esta é uma referência direta à variável secreta e funciona. -
$env:MYSECRET: Isto tenta acessar a variável secreta como variável de ambiente, o que não funciona porque as variáveis secretas não são automaticamente mapeadas para variáveis de ambiente. -
$env:GLOBAL_MYSECRET: Isto tenta acessar a variável secreta através de uma variável global, o que também não funciona porque as variáveis secretas não podem ser mapeadas desta maneira. -
$env:GLOBAL_MY_MAPPED_ENV_VAR: Este acessa a variável não secreta através de uma variável global, que funciona. -
$env:MY_MAPPED_ENV_VAR: Isso acessa a variável secreta por meio de uma variável de ambiente específica da tarefa, que é a maneira recomendada de mapear variáveis secretas para variáveis de ambiente.
variables:
GLOBAL_MYSECRET: $(mySecret) # this will not work because the secret variable needs to be mapped as env
GLOBAL_MY_MAPPED_ENV_VAR: $(nonSecretVariable) # this works because it's not a secret.
steps:
- powershell: |
Write-Host "Using an input-macro works: $(mySecret)"
Write-Host "Using the env var directly does not work: $env:MYSECRET"
Write-Host "Using a global secret var mapped in the pipeline does not work either: $env:GLOBAL_MYSECRET"
Write-Host "Using a global non-secret var mapped in the pipeline works: $env:GLOBAL_MY_MAPPED_ENV_VAR"
Write-Host "Using the mapped env var for this task works and is recommended: $env:MY_MAPPED_ENV_VAR"
env:
MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable
- bash: |
echo "Using an input-macro works: $(mySecret)"
echo "Using the env var directly does not work: $MYSECRET"
echo "Using a global secret var mapped in the pipeline does not work either: $GLOBAL_MYSECRET"
echo "Using a global non-secret var mapped in the pipeline works: $GLOBAL_MY_MAPPED_ENV_VAR"
echo "Using the mapped env var for this task works and is recommended: $MY_MAPPED_ENV_VAR"
env:
MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable
A saída de ambas as tarefas no script anterior é a seguinte:
Using an input-macro works: ***
Using the env var directly does not work:
Using a global secret var mapped in the pipeline does not work either:
Using a global non-secret var mapped in the pipeline works: foo
Using the mapped env var for this task works and is recommended: ***
Você também pode usar variáveis secretas fora de scripts. Por exemplo, pode mapear variáveis secretas para tarefas usando a variables definição. Este exemplo mostra como usar variáveis secretas $(vmsUser) e $(vmsAdminPass) numa tarefa de copiar ficheiros Azure.
variables:
VMS_USER: $(vmsUser)
VMS_PASS: $(vmsAdminPass)
pool:
vmImage: 'ubuntu-latest'
steps:
- task: AzureFileCopy@6
inputs:
SourcePath: 'my/path' # Specify the source path
azureSubscription: 'my-subscription' # Azure subscription name
Destination: 'AzureVMs' # Destination type
storage: 'my-storage' # Azure storage account name
resourceGroup: 'my-resource-group' # Resource group name
vmsAdminUserName: $(VMS_USER) # Admin username for the VM
vmsAdminPassword: $(VMS_PASS) # Admin password for the VM
CleanTargetBeforeCopy: false # Do not clean the target before copying
Variáveis secretas de referência em grupos de variáveis
Este exemplo mostra como fazer referência a um grupo de variáveis em seu arquivo YAML e também como adicionar variáveis dentro do YAML. O exemplo utiliza duas variáveis do grupo de variáveis: user e token. A token variável é secreta e está mapeada para a variável $env:MY_MAPPED_TOKEN ambiente para que possas consultá-la no YAML.
Este YAML faz uma chamada REST para recuperar uma lista de versões e produz o resultado.
variables:
- group: 'my-var-group' # variable group
- name: 'devopsAccount' # new variable defined in YAML
value: 'contoso'
- name: 'projectName' # new variable defined in YAML
value: 'contosoads'
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
# Encode the Personal Access Token (PAT)
# $env:USER is a normal variable in the variable group
# $env:MY_MAPPED_TOKEN is a mapped secret variable
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $env:USER,$env:MY_MAPPED_TOKEN)))
# Get a list of releases
$uri = "https://vsrm.dev.azure.com/$(devopsAccount)/$(projectName)/_apis/release/releases?api-version=5.1"
# Invoke the REST call
$result = Invoke-RestMethod -Uri $uri -Method Get -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}
# Output releases in JSON
Write-Host $result.value
env:
MY_MAPPED_TOKEN: $(token) # Maps the secret variable $(token) from my-var-group
Importante
Por defeito, com repositórios do GitHub, as builds de pedidos de pull de forks não conseguem aceder a variáveis secretas associadas ao seu pipeline. Para mais informações, consulte Contribuições de forks.
Partilhar variáveis entre pipelines
Para partilhar variáveis entre múltiplos pipelines no seu projeto, use a interface web. Em Biblioteca, use grupos de variáveis.
Usar variáveis de saída de tarefas
Algumas tarefas definem variáveis de saída, que pode usar em etapas, trabalhos e fases posteriores. No YAML, pode aceder a variáveis entre tarefas e fases usando dependencies.
Ao referenciar tarefas matriciais em tarefas a jusante, use uma sintaxe diferente. Consulte Definir uma variável de saída para múltiplos trabalhos. Você também precisa usar uma sintaxe diferente para variáveis em trabalhos de implantação. Consulte Suporte para variáveis de saída em trabalhos de implementação.
- Para fazer referência a uma variável de uma tarefa diferente dentro do mesmo trabalho, use
TASK.VARIABLE. - Para fazer referência a uma variável de uma tarefa de um trabalho diferente, use
dependencies.JOB.outputs['TASK.VARIABLE'].
Nota
Por padrão, cada estágio em um pipeline depende daquele imediatamente anterior no arquivo YAML. Se você precisar se referir a um estágio que não seja imediatamente anterior ao atual, poderá substituir esse padrão automático adicionando uma dependsOn seção ao estágio.
Nota
Os exemplos a seguir usam sintaxe de pipeline padrão. Se você estiver a usar pipelines de implementação, a sintaxe das variáveis e das variáveis condicionais será diferente. Para obter informações sobre a sintaxe específica a ser usada, consulte Trabalhos de implantação.
Para estes exemplos, suponha que tem uma tarefa chamada MyTask, que define uma variável de saída chamada MyVar.
Saiba mais sobre a sintaxe em Expressões - Dependências.
Utilizar saídas na mesma tarefa
steps:
- task: MyTask@1 # this step generates the output variable
name: ProduceVar # because we're going to depend on it, we need to name the step
- script: echo $(ProduceVar.MyVar) # this step uses the output variable
Utilizar resultados num trabalho diferente
jobs:
- job: A
steps:
# assume that MyTask generates an output variable called "MyVar"
# (you would learn that from the task's documentation)
- task: MyTask@1
name: ProduceVar # because we're going to depend on it, we need to name the step
- job: B
dependsOn: A
variables:
# map the output variable from A into this job
varFromA: $[ dependencies.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
Usar saídas em estágio diferente
Para usar a saída de uma fase diferente, use o formato stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE'] para referenciar variáveis. No nível do estágio, mas não no nível do trabalho, você pode usar essas variáveis em condições.
As variáveis de saída só estão disponíveis na próxima etapa seguinte no fluxo. Se vários estágios consumirem a mesma variável de saída, use a dependsOn condição.
stages:
- stage: One
jobs:
- job: A
steps:
- task: MyTask@1 # this step generates the output variable
name: ProduceVar # because we're going to depend on it, we need to name the step
- stage: Two
dependsOn:
- One
jobs:
- job: B
variables:
# map the output variable from A into this job
varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
- stage: Three
dependsOn:
- One
- Two
jobs:
- job: C
variables:
# map the output variable from A into this job
varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
Também podes passar variáveis entre fases usando uma entrada de ficheiro. Para fazer isso, precisas de definir variáveis na segunda fase a nível de trabalho, e depois passar as variáveis como entradas env:.
## script-a.sh
echo "##vso[task.setvariable variable=sauce;isOutput=true]crushed tomatoes"
## script-b.sh
echo 'Hello file version'
echo $skipMe
echo $StageSauce
## azure-pipelines.yml
stages:
- stage: one
jobs:
- job: A
steps:
- task: Bash@3
inputs:
filePath: 'script-a.sh'
name: setvar
- bash: |
echo "##vso[task.setvariable variable=skipsubsequent;isOutput=true]true"
name: skipstep
- stage: two
jobs:
- job: B
variables:
- name: StageSauce
value: $[ stageDependencies.one.A.outputs['setvar.sauce'] ]
- name: skipMe
value: $[ stageDependencies.one.A.outputs['skipstep.skipsubsequent'] ]
steps:
- task: Bash@3
inputs:
filePath: 'script-b.sh'
name: fileversion
env:
StageSauce: $(StageSauce) # predefined in variables section
skipMe: $(skipMe) # predefined in variables section
- task: Bash@3
inputs:
targetType: 'inline'
script: |
echo 'Hello inline version'
echo $(skipMe)
echo $(StageSauce)
A saída das etapas no pipeline anterior apresenta a seguinte aparência:
Hello inline version
true
crushed tomatoes
Listar variáveis
Liste todas as variáveis do seu pipeline usando o comando az pipelines variable list. Para começar, veja Introdução com Azure DevOps CLI.
az pipelines variable list [--org]
[--pipeline-id]
[--pipeline-name]
[--project]
Parâmetros
-
org: URL da organização Azure DevOps. Configure a organização por defeito usando
az devops configure -d organization=ORG_URL. Obrigatório se não estiver configurado como padrão ou coletado usandogit config. Exemplo:--org https://dev.azure.com/MyOrganizationName/. - pipeline-id: Obrigatório se o nome do pipeline não for fornecido. ID da cadeia de processos.
- pipeline-name: Necessário caso pipeline-id não seja fornecido, mas é ignorado caso pipeline-id seja fornecido. Nome da cadeia de processamento.
-
project: Nome ou ID do project. Configurar o projeto padrão usando
az devops configure -d project=NAME_OR_ID. Obrigatório se não estiver configurado como padrão ou coletado usandogit config.
Exemplo
O comando a seguir lista todas as variáveis no pipeline com ID 12 e mostra o resultado em formato de tabela.
az pipelines variable list --pipeline-id 12 --output table
Name Allow Override Is Secret Value
------------- ---------------- ----------- ------------
MyVariable False False platform
NextVariable False True platform
Configuration False False config.debug
Definir variáveis em scripts
Scripts podem definir variáveis que os passos seguintes do pipeline consomem. Todas as variáveis definidas por este método são tratadas como strings. Para definir uma variável a partir de um script, usa uma sintaxe de comandos e imprime para stdout.
Definir uma variável de escopo de trabalho a partir de um script
Para definir uma variável a partir de um script, use o task.setvariablecomando loging. Este comando atualiza as variáveis de ambiente para trabalhos subsequentes. Trabalhos subsequentes podem acessar a nova variável usando sintaxe macro e nas tarefas como variáveis de ambiente.
Quando defines issecret para verdadeiro, o valor da variável é guardado como secreto e mascarado do registo. Para mais informações sobre variáveis secretas, consulte comandos de registo.
steps:
# Create a variable
- bash: |
echo "##vso[task.setvariable variable=sauce]crushed tomatoes" # remember to use double quotes
# Use the variable
# "$(sauce)" is replaced by the contents of the `sauce` variable by Azure Pipelines
# before handing the body of the script to the shell.
- bash: |
echo my pipeline variable is $(sauce)
Os passos seguintes também têm a variável pipeline adicionada ao seu ambiente. Não é possível usar a variável na etapa em que ela está definida.
steps:
# Create a variable
# Note that this does not update the environment of the current script.
- bash: |
echo "##vso[task.setvariable variable=sauce]crushed tomatoes"
# An environment variable called `SAUCE` has been added to all downstream steps
- bash: |
echo "my environment variable is $SAUCE"
- pwsh: |
Write-Host "my environment variable is $env:SAUCE"
A saída do pipeline anterior.
my environment variable is crushed tomatoes
my environment variable is crushed tomatoes
Definir uma variável de saída para múltiplos trabalhos
Se quiser disponibilizar uma variável para trabalhos futuros, marque-a como uma variável de saída usando isOutput=true. Em seguida, você pode mapeá-lo em trabalhos futuros usando a $[] sintaxe e incluindo o nome da etapa que definiu a variável. As variáveis de saída para várias tarefas só funcionam para tarefas no mesmo estágio.
Para passar variáveis para trabalhos em diferentes estágios, use a sintaxe de dependências de estágio.
Nota
Por padrão, cada estágio em um pipeline depende daquele imediatamente anterior no arquivo YAML. Portanto, cada estágio pode usar variáveis de saída do estágio anterior. Para acess a etapas seguintes, terá de alterar o grafo de dependências, por exemplo, se a etapa 3 exigir uma variável da etapa 1, terá de declarar uma dependência explícita na etapa 1.
Ao criar uma variável de saída de múltiplos trabalhos, deve-se atribuir a expressão a uma variável. Neste YAML, $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] é atribuído à variável $(myVarFromJobA).
jobs:
# Set an output variable from job A
- job: A
pool:
vmImage: 'windows-latest'
steps:
- powershell: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable into job B
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] # map in the variable
# remember, expressions require single quotes
steps:
- script: echo $(myVarFromJobA)
name: echovar
A saída do pipeline anterior.
this is the value
this is the value
Se você estiver definindo uma variável de um estágio para outro, use stageDependencies.
stages:
- stage: A
jobs:
- job: A1
steps:
- bash: echo "##vso[task.setvariable variable=myStageOutputVar;isOutput=true]this is a stage output var"
name: printvar
- stage: B
dependsOn: A
variables:
myVarfromStageA: $[ stageDependencies.A.A1.outputs['printvar.myStageOutputVar'] ]
jobs:
- job: B1
steps:
- script: echo $(myVarfromStageA)
Se estiver a definir uma variável a partir de uma matrix ou slice, então para referenciar a variável quando o aceder de uma tarefa subsequente, deve incluir:
- O nome da tarefa.
- O passo.
jobs:
# Set an output variable from a job with a matrix
- job: A
pool:
vmImage: 'ubuntu-latest'
strategy:
maxParallel: 2
matrix:
debugJob:
configuration: debug
platform: x64
releaseJob:
configuration: release
platform: x64
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the $(configuration) value"
name: setvarStep
- bash: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the debug job
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobADebug: $[ dependencies.A.outputs['debugJob.setvarStep.myOutputVar'] ]
steps:
- script: echo $(myVarFromJobADebug)
name: echovar
jobs:
# Set an output variable from a job with slicing
- job: A
pool:
vmImage: 'ubuntu-latest'
parallel: 2 # Two slices
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the slice $(system.jobPositionInPhase) value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the job for the first slice
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
steps:
- script: "echo $(myVarFromJobsA1)"
name: echovar
Certifique-se de prefixar o nome do trabalho às variáveis de saída de um trabalho de implantação. Neste caso, o nome do trabalho é A:
jobs:
# Set an output variable from a deployment
- deployment: A
pool:
vmImage: 'ubuntu-latest'
environment: staging
strategy:
runOnce:
deploy:
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
name: setvarStep
- bash: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the job for the first slice
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
steps:
- bash: "echo $(myVarFromDeploymentJob)"
name: echovar
Definir as variáveis 
Definir as variáveis 
Definir as variáveis Definir variáveis usando expressões
Você pode definir uma variável usando uma expressão. Já encontraste um caso desta abordagem quando defines uma variável para a saída de outra variável de um trabalho anterior.
- job: B
dependsOn: A
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ] # remember to use single quotes
Você pode usar qualquer uma das expressões suportadas para definir uma variável. Aqui está um exemplo de configuração de uma variável para atuar como um contador que começa em 100, é incrementado em 1 para cada execução e é redefinido para 100 todos os dias.
jobs:
- job:
variables:
a: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 100)]
steps:
- bash: echo $(a)
Para obter mais informações sobre contadores, dependências e outras expressões, consulte expressões.
Configurar variáveis ajustáveis para etapas
Você pode definir settableVariables dentro de uma etapa ou especificar que nenhuma variável pode ser definida.
Neste exemplo, o script não pode definir uma variável.
steps:
- script: echo This is a step
target:
settableVariables: none
No exemplo seguinte, o script pode definir a variável sauce mas não pode definir a variável secretSauce. Você vê um aviso na página de execução do pipeline.
steps:
- bash: |
echo "##vso[task.setvariable variable=Sauce;]crushed tomatoes"
echo "##vso[task.setvariable variable=secretSauce;]crushed tomatoes with garlic"
target:
settableVariables:
- sauce
name: SetVars
- bash:
echo "Sauce is $(sauce)"
echo "secretSauce is $(secretSauce)"
name: OutputVars
Permitir durante o tempo de espera na fila
Se uma variável aparecer num bloco de um ficheiro YAML, o seu valor é fixo e os utilizadores não podem substituí-lo durante o tempo de execução. Define as tuas variáveis num ficheiro YAML, mas há momentos em que esta abordagem não faz sentido. Por exemplo, pode querer definir uma variável secreta e não a expor no seu YAML. Ou, talvez seja necessário definir manualmente um valor variável durante a execução do pipeline.
Você tem duas opções para definir valores de tempo de fila. Você pode definir uma variável na IU e selecionar a opção de Permitir que os utilizadores substituam este valor ao executar este pipeline ou pode usar parâmetros de tempo de execução. Se sua variável não for um segredo, a prática recomendada é usar parâmetros de tempo de execução.
Para definir uma variável no momento da fila, adicione uma nova variável dentro do pipeline e selecione a opção de substituição. Apenas utilizadores com a permissão para a configuração de compilação da fila de edição podem alterar o valor de uma variável.
Para permitir que uma variável seja definida no momento da fila, certifique-se de que a variável não apareça também no bloco variables de um pipeline ou tarefa. Se você definir uma variável no bloco de variáveis de um YAML e na interface do usuário, o valor no YAML terá prioridade.
Para maior segurança, use um conjunto predefinido de valores para variáveis ajustáveis no tempo de espera e tipos seguros, como Boolean e Inteiro. Para cadeias de caracteres, use um conjunto predefinido de valores.
Expansão de variáveis
Quando se define uma variável com o mesmo nome em múltiplos escopos, aplica-se a seguinte precedência (a precedência máxima primeiro):
- Variável ao nível do trabalho definida no ficheiro YAML
- Variável ao nível da fase definida no ficheiro YAML
- Variável de nível de pipeline definida no ficheiro YAML
- Variável definida no tempo de fila
- Variável de pipeline definida na interface do utilizador de definições do pipeline
No exemplo seguinte, a mesma variável a é definida ao nível do pipeline e ao nível do job no ficheiro YAML. Isso também está definido num grupo de variáveis G e como uma variável nas definições da interface do utilizador do Pipeline.
variables:
a: 'pipeline yaml'
stages:
- stage: one
displayName: one
variables:
- name: a
value: 'stage yaml'
jobs:
- job: A
variables:
- name: a
value: 'job yaml'
steps:
- bash: echo $(a) # This will be 'job yaml'
Quando você define uma variável com o mesmo nome no mesmo escopo, o último valor definido tem precedência.
stages:
- stage: one
displayName: Stage One
variables:
- name: a
value: alpha
- name: a
value: beta
jobs:
- job: I
displayName: Job I
variables:
- name: b
value: uno
- name: b
value: dos
steps:
- script: echo $(a) #outputs beta
- script: echo $(b) #outputs dos
Nota
Quando definir uma variável no arquivo YAML, não a configure no editor da Web como ajustável no momento da fila. No momento, não é possível alterar variáveis definidas no arquivo YAML no momento da fila. Se você precisar que uma variável seja configurável no momento da fila, não a defina no arquivo YAML.
As variáveis são expandidas uma vez no início da corrida e novamente no início de cada passo. Por exemplo:
jobs:
- job: A
variables:
a: 10
steps:
- bash: |
echo $(a) # This will be 10
echo '##vso[task.setvariable variable=a]20'
echo $(a) # This will also be 10, since the expansion of $(a) happens before the step
- bash: echo $(a) # This will be 20, since the variables are expanded just before the step
Há duas etapas no exemplo anterior. A expansão de $(a) acontece uma vez no início do trabalho, e uma vez no início de cada uma das duas etapas.
Como as variáveis são expandidas no início de um trabalho, você não pode usá-las em uma estratégia. No exemplo a seguir, você não pode usar a variável a para expandir a matriz de trabalho, porque a variável só está disponível no início de cada trabalho expandido.
jobs:
- job: A
variables:
a: 10
strategy:
matrix:
x:
some_variable: $(a) # This does not work
Se a variável a for uma variável de saída de um trabalho anterior, você poderá usá-la em um trabalho futuro.
- job: A
steps:
- powershell: echo "##vso[task.setvariable variable=a;isOutput=true]10"
name: a_step
# Map the variable into job B
- job: B
dependsOn: A
variables:
some_variable: $[ dependencies.A.outputs['a_step.a'] ]
Expansão recursiva
No agente, as variáveis referenciadas usando $( ) sintaxe são expandidas recursivamente.
Por exemplo:
variables:
myInner: someValue
myOuter: $(myInner)
steps:
- script: echo $(myOuter) # prints "someValue"
displayName: Variable is $(myOuter) # display name is "Variable is someValue"