Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Os parâmetros de runtime oferecem mais controle sobre os valores que você passa para um pipeline. Com parâmetros de runtime, você pode:
- Fornecer valores diferentes para scripts e tarefas em runtime
- Tipos de parâmetro de controle, intervalos permitidos e valores padrão
- Selecionar dinamicamente trabalhos e estágios com expressões de modelo
Você pode especificar parâmetros em modelos e no pipeline. Os parâmetros têm tipos de dados como e string e podem ser restritos a um subconjunto de valores. A seção parameters em um YAML define quais parâmetros estão disponíveis.
Os parâmetros só estão disponíveis durante a análise de modelo. Eles se expandem antes da execução do pipeline, substituindo os valores cercados por ${{ }} pelos valores dos parâmetros. Use variáveis se os valores precisarem estar disponíveis durante a execução de todo o pipeline.
Observação
Essas diretrizes não se aplicam a pipelines clássicos. Para parâmetros em pipelines clássicos, confira Parâmetros de processo (clássico).
Os parâmetros devem conter um nome e um tipo de dados. Você não pode tornar os parâmetros opcionais. Você precisa atribuir um valor padrão no arquivo YAML ou ao executar o pipeline. Se você não atribuir um valor padrão ou definir default como false, o primeiro valor disponível será usado.
Use templateContext para passar mais propriedades para estágios, etapas e trabalhos usados como parâmetros em um modelo.
Qual é a diferença entre parâmetros e variáveis?
A tabela a seguir destaca as principais diferenças entre parâmetros e variáveis no Azure Pipelines.
| Característica | Parâmetros | Variáveis |
|---|---|---|
| Tempo de Avaliação | Análise de modelo (fila) | A avaliação depende da sintaxe. Variáveis definidas com sintaxe de macro ($(var)) são avaliadas em runtime antes que uma tarefa seja executada e usada em scripts e tarefas. As variáveis definidas com expressões de runtime ($[variables.var]) são avaliadas antes da execução de um trabalho ou etapa e são usadas em condições ou em atribuição dinâmica de variáveis. |
| Mutabilidade | Imutável após fila | As variáveis definidas pelo usuário, de ambiente e de saída podem ser atualizadas dinamicamente durante a execução do pipeline |
| Exposição da interface do usuário durante a execução | Mostrado na interface do usuário do Run Pipeline e pode ser definido antes de uma execução | Exposto durante a execução se definido na interface do usuário do Pipeline como substituível |
| Valores secretos | Sem suporte para valores secretos | Pode ser definido como segredos |
Usar parâmetros em pipelines
Defina parâmetros de runtime no início de um arquivo YAML.
Esse pipeline de exemplo inclui um parâmetro image com três agentes hospedados como opções string. Na seção trabalhos, o valor pool especifica o agente do parâmetro usado para executar o trabalho. O trigger é definido como nenhum para que você possa selecionar o valor de image ao disparar manualmente o pipeline para execução.
parameters:
- name: image
displayName: Pool Image
type: string
default: ubuntu-latest
values:
- windows-latest
- ubuntu-latest
- macOS-latest
trigger: none
jobs:
- job: build
displayName: build
pool:
vmImage: ${{ parameters.image }}
steps:
- script: echo building $(Build.BuildNumber) with ${{ parameters.image }}
Na página de execuções de pipeline, selecione Executar pipeline para executar o pipeline. Você verá a opção para selecionar a Imagem do Pool. Se você não fizer uma seleção, a opção ubuntu-latest padrão será usada. Você não poderá selecionar uma Imagem do Pool se executar o pipeline no editor do YAML.
Usar condicionais com parâmetros
Você também pode usar parâmetros como parte da lógica condicional. Com condicionais, parte de um YAML será executada se atender aos critérios if.
Usar parâmetros para determinar quais etapas são executadas
Esse pipeline adiciona um segundo parâmetro booliano, testque controla se os testes devem ser executados no pipeline. Quando o valor de test é true, a etapa que gera Executar todos os testes é executada.
parameters:
- name: image
displayName: Pool Image
values:
- windows-latest
- ubuntu-latest
- macOS-latest
- name: test
displayName: Run Tests?
type: boolean
default: false
trigger: none
jobs:
- job: build
displayName: Build and Test
pool:
vmImage: ${{ parameters.image }}
steps:
- script: echo building $(Build.BuildNumber)
- ${{ if eq(parameters.test, true) }}:
- script: echo "Running all the tests"
Usar parâmetros para definir qual configuração é usada
Você também pode usar parâmetros para definir quais trabalhos são executados. Neste exemplo, diferentes arquiteturas são compiladas dependendo do valor do parâmetro config, que é um tipo string. Por padrão, as arquiteturas x86 e x64 são criadas.
parameters:
- name: configs
type: string
default: 'x86,x64'
trigger: none
jobs:
- ${{ if contains(parameters.configs, 'x86') }}:
- job: x86
steps:
- script: echo Building x86...
- ${{ if contains(parameters.configs, 'x64') }}:
- job: x64
steps:
- script: echo Building x64...
- ${{ if contains(parameters.configs, 'arm') }}:
- job: arm
steps:
- script: echo Building arm...
Excluir seletivamente uma fase
Você também pode usar parâmetros para definir se uma fase é executada. Neste exemplo, há um pipeline com quatro fases e trabalhos diferentes para cada fase. A fase teste de desempenho será executada se o parâmetro runPerfTests for true. O valor runPerfTests padrão é false, portanto, apenas três dos quatro estágios são executados, a menos que você atualize o valor.
parameters:
- name: runPerfTests
type: boolean
default: false
trigger: none
stages:
- stage: Build
displayName: Build
jobs:
- job: Build
steps:
- script: echo running Build
- stage: UnitTest
displayName: Unit Test
dependsOn: Build
jobs:
- job: UnitTest
steps:
- script: echo running UnitTest
- ${{ if eq(parameters.runPerfTests, true) }}:
- stage: PerfTest
displayName: Performance Test
dependsOn: Build
jobs:
- job: PerfTest
steps:
- script: echo running PerfTest
- stage: Deploy
displayName: Deploy
dependsOn: UnitTest
jobs:
- job: Deploy
steps:
- script: echo running UnitTest
Verificar se há um objeto de parâmetro vazio
Use a length()expressão para verificar se um parâmetro de objeto não tem valor.
parameters:
- name: foo
type: object
default: []
steps:
- checkout: none
- ${{ if eq(length(parameters.foo), 0) }}:
- script: echo Foo is empty
displayName: Foo is empty
Tipos de dados do parâmetro
| Tipo de dados | Observações |
|---|---|
string |
cadeia |
stringList |
uma lista de itens, vários podem ser selecionados. Não disponível em modelos |
number |
pode ser restrito a values:, caso contrário, qualquer cadeia de caracteres semelhante a número será aceita |
boolean |
true ou false |
object |
qualquer estrutura do YAML |
step |
uma etapa única |
stepList |
sequência de etapas |
job |
um trabalho único |
jobList |
sequência de trabalhos |
deployment |
um trabalho de implantação única |
deploymentList |
sequência de trabalhos de implantação |
stage |
uma fase única |
stageList |
sequência de fases |
Os step, stepList, job, jobList, deployment, deploymentList, stage, stringList e stageList tipos de dados, todos usam o formato de esquema YAML padrão. Este exemplo inclui string, number, , boolean, object, stepe stepList.
Observação
O stringList tipo de dados não está disponível em modelos. Em vez disso, use o object tipo de dados em modelos.
parameters:
- name: myString # Define a parameter named 'myString'
type: string # The parameter type is string
default: a string # Default value is 'a string'
- name: myMultiString # Define a parameter named 'myMultiString'
type: string # The parameter type is string
default: default # Default value is 'default', only one default
values: # Allowed values for 'myMultiString'
- default
- ubuntu
- name: myStringlist # Define a parameter named 'myStringlist'
type: stringList # The parameter type is stringList
displayName: Regions
values: # Allowed values for 'myStringlist'
- WUS
- CUS
- EUS
default: # Default values
- WUS
- CUS
- name: myNumber # Define a parameter named 'myNumber'
type: number # The parameter type is number
default: 2 # Default value is 2
values: # Allowed values for 'myNumber'
- 1
- 2
- 4
- 8
- 16
- name: myBoolean # Define a parameter named 'myBoolean'
type: boolean # The parameter type is boolean
default: true # Default value is true
- name: myObject # Define a parameter named 'myObject'
type: object # The parameter type is object
default: # Default value is an object with nested properties
foo: FOO # Property 'foo' with value 'FOO'
bar: BAR # Property 'bar' with value 'BAR'
things: # Property 'things' is a list
- one
- two
- three
nested: # Property 'nested' is an object
one: apple # Property 'one' with value 'apple'
two: pear # Property 'two' with value 'pear'
count: 3 # Property 'count' with value 3
- name: myStep # Define a parameter named 'myStep'
type: step # The parameter type is step
default: # Default value is a step
script: echo my step
- name: mySteplist # Define a parameter named 'mySteplist'
type: stepList # The parameter type is stepList
default: # Default value is a list of steps
- script: echo step one
- script: echo step two
trigger: none
jobs:
- job: stepList # Define a job named 'stepList'
steps: ${{ parameters.mySteplist }} # Use the steps from the 'mySteplist' parameter
- job: myStep # Define a job named 'myStep'
steps:
- ${{ parameters.myStep }} # Use the step from the 'myStep' parameter
- job: stringList # Define a job named 'stringList'
steps:
- ${{ each region in parameters.myStringlist }}:
- script: echo ${{region}}
Práticas recomendadas de segurança de parâmetro
Ao usar parâmetros de runtime no Azure Pipelines, não passe segredos ou valores confidenciais como entradas de parâmetro. Os valores de parâmetro são expandidos durante o parsing do modelo e podem ser expostos em logs ou saídas de pipeline.
Sempre valide e restrinja valores de parâmetro permitidos para evitar a injeção de entrada inesperada ou não segura. Siga o princípio do privilégio mínimo ao conceder acesso aos recursos de pipeline.
Para credenciais, tokens ou outros dados confidenciais, use variáveis de pipeline marcadas como segredos e armazenadas no Azure Key Vault, na interface do usuário do Pipeline ou em grupos de variáveis. Para obter mais informações, consulte Proteger segredos no Azure Pipelines.