Definición de variables
Nota:
En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.
Las variables proporcionan una manera cómoda de obtener los bits clave de los datos en varias partes de la canalización. El uso más común de las variables es definir un valor que pueda usar en la canalización. Todas las variables se almacenan como cadenas y son mutables. El valor de una variable puede cambiar de ejecución a ejecución o trabajo a trabajo de la canalización.
Al definir la misma variable en varios lugares con el mismo nombre, la variable con ámbito más local gana. Por lo tanto, una variable definida en el nivel de trabajo puede invalidar un conjunto de variables en el nivel de fase. Una variable definida en el nivel de fase invalidará un conjunto de variables en el nivel raíz de la canalización. Un conjunto de variables en el nivel raíz de canalización invalidará un conjunto de variables en la interfaz de usuario configuración de canalización.
Puede usar variables con expresiones para asignar valores condicionalmente y personalizar aún más las canalizaciones.
Las variables son diferentes de los parámetros en tiempode ejecución, que se escriben y están disponibles durante el análisis de plantillas.
Variables definidas por el usuario
Al definir una variable, puede usar sintaxis diferentes (macro, expresión de plantilla o tiempo de ejecución) y qué sintaxis usará determinará dónde se representará la variable en la canalización.
En las canalizaciones de YAML, puede establecer variables en el nivel raíz, fase y trabajo. También puede especificar variables fuera de una canalización de YAML en la interfaz de usuario. Cuando se establece una variable en la interfaz de usuario, esa variable se puede cifrar y establecer como secreto.
Las variables definidas por el usuario se pueden establecer como de solo lectura. Hay restricciones de nomenclatura para las variables (por ejemplo: no se puede usar al principio de un nombre de variable).
Puede usar un grupo de variables para que las variables estén disponibles en varias canalizaciones.
Puede usar plantillas para definir variables que se usan en varias canalizaciones en un archivo.
Variables del sistema
Además de las variables definidas por el usuario, Azure Pipelines variables del sistema con valores predefinidos. Si usa YAML o canalizaciones de compilación clásicas, consulte variables predefinidas para obtener una lista completa de variables del sistema. Si usa canalizaciones de versión clásicas, consulte variables de versión.
Las variables del sistema se establecen con su valor actual al ejecutar la canalización. Algunas variables se establecen automáticamente. Como autor de la canalización o usuario final, se cambia el valor de una variable del sistema antes de ejecutar la canalización.
Las variables del sistema son de solo lectura.
Variables de entorno
Las variables de entorno son específicas del sistema operativo que se usa. Se insertan en una canalización de maneras específicas de la plataforma. El formato corresponde a cómo se formatearán las variables de entorno para la plataforma de scripting específica.
En UNIX (macOS y Linux), las variables de entorno tienen el formato $NAME . En Windows, el formato es %NAME% para batch y en $env:NAME PowerShell.
Las variables definidas por el sistema y por el usuario también se insertan como variables de entorno para la plataforma. Cuando las variables se convierten en variables de entorno, los nombres de variable se convierten en mayúsculas y los puntos se convierten en caracteres de subrayado. Por ejemplo, el nombre de la variable any.variable se convierte en el nombre de variable $ANY_VARIABLE .
Restricciones de nomenclatura de variables
Las variables definidas por el usuario pueden constar de letras, . números, y _ caracteres. No use prefijos de variable reservados por el sistema. Estos son: endpoint , input , y secretsecurefile . Cualquier variable que comience con una de estas cadenas (independientemente de la mayúsculas y las mayúsculas) no estará disponible para las tareas y scripts.
Comprender la sintaxis de las variables
Azure Pipelines admite tres maneras diferentes de hacer referencia a variables: macro, expresión de plantilla y expresión en tiempo de ejecución. Cada sintaxis se puede usar para un propósito diferente y tiene algunas limitaciones.
En una canalización, las variables de expresión de plantilla ( ${{ variables.var }} ) se procesan en tiempo de compilación, antes de que se inicie el tiempo de ejecución. Las variables de sintaxis de macro ( $(var) ) se procesan durante el tiempo de ejecución antes de que se ejecute una tarea. Las expresiones en tiempo de ejecución ( ) también se procesan durante el tiempo de ejecución, pero se diseñaron $[variables.var] para su uso con $[variables.var]y expresiones. Cuando se usa una expresión en tiempo de ejecución, debe tomar todo el lado derecho de una definición.
En este ejemplo, puede ver que la expresión de plantilla todavía tiene el valor inicial de la variable después de actualizar la variable. El valor de la variable de sintaxis de macro se actualiza. El valor de la expresión de plantilla no cambia porque todas las variables de expresión de plantilla se procesan en tiempo de compilación antes de que se ejecuten las tareas. Por el contrario, las variables de sintaxis de macro se evalúan antes de que se ejecute cada tarea.
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
Variables de sintaxis de macro
La mayoría de los ejemplos de documentación usan la sintaxis de macro ( $(var) ). La sintaxis de macro está diseñada para interpolar valores de variable en entradas de tareas y en otras variables.
Las variables con sintaxis de macro se procesan antes de que una tarea se ejecute durante el tiempo de ejecución. El tiempo de ejecución se produce después de la expansión de la plantilla. Cuando el sistema encuentra una expresión de macro, reemplaza la expresión por el contenido de la variable. Si no hay ninguna variable por ese nombre, la expresión de macro se deja sin modificar. Por ejemplo, $(var) si no se puede reemplazar, no se $(var) reemplazará por nada.
Las variables de sintaxis de macro permanecen sin cambios sin ningún valor porque un valor vacío como podría significar algo para la tarea que se está ejecutando y el agente no debe suponer que desea reemplazar $() ese valor. Por ejemplo, si usa para hacer referencia a una variable en una tarea de Bash, reemplazar todas las expresiones de la entrada a la tarea podría interrumpir los $(foo)foo scripts de $() Bash.
Las variables de macro solo se expanden cuando se usan para un valor, no como una palabra clave. Los valores aparecen en el lado derecho de una definición de canalización. Lo siguiente es válido: key: $(value) . Lo siguiente no es válido: $(key): value . Las variables de macro no se expanden cuando se usan para mostrar un nombre de trabajo en línea. En su lugar, debe usar la displayName propiedad .
Nota:
Las variables de sintaxis de macro solo se expanden stages para jobs , y steps .
Por ejemplo, no puede usar la sintaxis de macro dentro de resource o trigger .
En este ejemplo, se usa la sintaxis de macro con Bash, PowerShell y una tarea de script. La sintaxis para llamar a una variable con sintaxis de macro es la misma para las tres.
variables:
- name: projectName
value: contoso
steps:
- bash: echo $(projectName)
- powershell: echo $(projectName)
- script: echo $(projectName)
Sintaxis de expresiones de plantilla
Puede usar la sintaxis de expresión de plantilla para expandir los parámetros de plantilla y las variables ( ). Las variables de plantilla se procesan en tiempo de compilación y se reemplazan antes de que se inicie el tiempo de ejecución. Las expresiones de plantilla están diseñadas para volver a usar partes de YAML como plantillas.
Las variables de plantilla se une silenciosamente a cadenas vacías cuando no se encuentra un valor de reemplazo. Las expresiones de plantilla, a diferencia de las expresiones de macro y tiempo de ejecución, pueden aparecer como claves (lado izquierdo) o valores (lado derecho). Lo siguiente es válido: ${{ variables.key }} : ${{ variables.value }} .
Sintaxis de expresiones en tiempo de ejecución
Puede usar la sintaxis de expresiones en tiempo de ejecución para las variables que se expanden en tiempo de ejecución ( $[variables.var] ). Las variables de expresión en tiempo de ejecución se integran silenciosamente en cadenas vacías cuando no se encuentra un valor de reemplazo. Las expresiones en tiempo de ejecución están diseñadas para usarse en las condiciones de los trabajos, para admitir la ejecución condicional de trabajos o fases enteras.
Las variables de expresión en tiempo de ejecución solo se expanden cuando se usan para un valor, no como una palabra clave. Los valores aparecen en el lado derecho de una definición de canalización. Lo siguiente es válido: key: $[variables.value] . Lo siguiente no es válido: $[variables.key]: value . La expresión en tiempo de ejecución debe tomar todo el lado derecho de un par clave-valor. Por ejemplo, key: $[variables.value] es válido, pero key: $[variables.value] foo no lo es.
| Sintaxis | Ejemplo | ¿Cuándo se procesa? | ¿Dónde se expande en una definición de canalización? | ¿Cómo se representa cuando no se encuentra? |
|---|---|---|---|---|
| macro | $(var) |
runtime antes de que se ejecute una tarea | value (lado derecho) | Huellas $(var) |
| expresión de plantilla | ${{ variables.var }} |
tiempo de compilación | clave o valor (lado izquierdo o derecho) | cadena vacía |
| expresión en tiempo de ejecución | $[variables.var] |
motor en tiempo de ejecución | value (lado derecho) | cadena vacía |
¿Qué sintaxis debo usar?
Use la sintaxis de macro si va a proporcionar entradas para una tarea.
Elija una expresión en tiempo de ejecución si está trabajando con condicionesy expresiones. La excepción a esto es si tiene una canalización en la que se producirá un problema para que la variable vacía se imprima. Por ejemplo, si tiene lógica condicional que se basa en una variable que tiene un valor específico o no tiene ningún valor. En ese caso, debe usar una expresión en tiempo de ejecución.
Si va a definir una variable en una plantilla, use una expresión de plantilla.
Establecer variables en la canalización
En el caso más común, se establecen las variables y se usan en el archivo YAML. Esto le permite realizar un seguimiento de los cambios en la variable en el sistema de control de versiones. También puede definir variables en la interfaz de usuario de configuración de canalización (consulte la pestaña Clásico) y hacer referencia a ellas en el ARCHIVO YAML.
Este es un ejemplo que muestra cómo establecer dos variables, configuration y platform , y usarlas más adelante en los pasos. Para usar una variable en una instrucción YAML, envolverla en $() . Las variables no se pueden usar para definir un repository en una instrucción 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)
Ámbitos de variables
En el archivo YAML, puede establecer una variable en varios ámbitos:
- En el nivel raíz, para que esté disponible para todos los trabajos de la canalización.
- En el nivel de fase, para que esté disponible solo para una fase específica.
- En el nivel de trabajo, para que esté disponible solo para un trabajo específico.
Cuando una variable se define en la parte superior de un YAML, estará disponible para todos los trabajos y fases de la canalización y es una variable global. Las variables globales definidas en un YAML no son visibles en la interfaz de usuario de configuración de canalización.
Las variables en el nivel de trabajo invalidan las variables en el nivel raíz y de fase. Las variables en el nivel de fase invalidan las variables en el nivel raíz.
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
La salida de ambos trabajos tiene el siguiente aspecto:
# job1
value
value1
value1
# job2
value
value2
value
Especificar variables
En los ejemplos anteriores, la palabra variables clave va seguida de una lista de pares clave-valor.
Las claves son los nombres de las variables y los valores son los valores de variable.
Hay otra sintaxis útil cuando se quieren usar plantillas de variables o grupos de variables. Esta sintaxis debe usarse en el nivel raíz de una canalización.
En esta sintaxis alternativa, la variables palabra clave toma una lista de especificadores de variables.
Los especificadores de variable name son para una variable normal, para un grupo de variables e para incluir una plantilla de grouptemplate variable.
En el ejemplo siguiente se muestran los tres.
variables:
# a regular variable
- name: myvariable
value: myvalue
# a variable group
- group: myvariablegroup
# a reference to a variable template
- template: myvariabletemplate.yml
Obtenga más información sobre la reutilización de variables con plantillas.
Acceso a variables a través del entorno
Observe que las variables también están disponibles para los scripts a través de variables de entorno. La sintaxis para usar estas variables de entorno depende del lenguaje de scripting.
El nombre está en mayúsculas y . se reemplaza por _ . Esto se inserta automáticamente en el entorno de proceso. Estos son algunos ejemplos:
- Script por lotes:
%VARIABLE_NAME% - Script de PowerShell:
$env:VARIABLE_NAME - Script de Bash:
$VARIABLE_NAME
Importante
Las variables predefinidas que contienen rutas de acceso de archivo se traducen al estilo adecuado (estilo Windows C:\foo\ frente al estilo unix /foo/) en función del tipo de host del agente y del tipo de shell. Si ejecuta tareas de script de Bash en Windows, debe usar el método de variable de entorno para acceder a estas variables en lugar del método de variable de canalización para asegurarse de que tiene el estilo de ruta de acceso de archivo correcto.
YAML no se admite en TFS.
Establecer variables secretas
No establezca variables secretas en el archivo YAML. Los sistemas operativos suelen registrar comandos para los procesos que se ejecutan y no le gustaría que el registro incluyese un secreto que pasó como entrada. Use el entorno del script o asigne la variable dentro del variables bloque para pasar secretos a la canalización.
Debe establecer variables secretas en la interfaz de usuario de configuración de canalización para la canalización. Estas variables tienen como ámbito la canalización en la que se establecen. También puede establecer variables secretas en grupos de variables.
Para establecer secretos en la interfaz web, siga estos pasos:
- Vaya a la página Canalizaciones, seleccione la canalización adecuada y, después, seleccione Editar.
- Busque las Variables de esta canalización.
- Agregue la variable o actualícela.
- Seleccione el
bloqueo secreto para almacenar la variable de forma cifrada. - Guarde la canalización.
Las variables secretas se cifran en reposo con una clave RSA de 2048 bits. Los secretos están disponibles en el agente para las tareas y scripts que se van a usar. Tenga cuidado con quién tiene acceso para modificar la canalización.
Importante
Hacemos un esfuerzo para que los secretos no aparezcan en Azure Pipelines salida, pero todavía es necesario tomar precauciones. Nunca se repiten los secretos como salida. Algunos sistemas operativos registra argumentos de línea de comandos. No pase nunca secretos en la línea de comandos. En su lugar, se recomienda asignar los secretos a variables de entorno.
Nunca enmascaramos subcadenas de secretos. Si, por ejemplo, "abc123" se establece como un secreto, "abc" no se enmascara en los registros. Esto es para evitar el enmascaramiento de secretos en un nivel demasiado granular, lo que hace que los registros no se ilegibles. Por esta razón, los secretos no deben contener datos estructurados. Si, por ejemplo, "{ "foo": "bar" }" se establece como un secreto, "bar" no se enmascara de los registros.
A diferencia de una variable normal, no se descifran automáticamente en variables de entorno para scripts. Debe asignar explícitamente variables secretas.
En el ejemplo siguiente se muestra cómo usar una variable secreta denominada mySecret en scripts de PowerShell y Bash.
A diferencia de una variable de canalización normal, no hay ninguna variable de entorno denominada MYSECRET .
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
La salida de ambas tareas en el script anterior tendría el siguiente aspecto:
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: ***
También puede usar variables secretas fuera de los scripts. Por ejemplo, puede asignar variables secretas a tareas mediante la variables definición. En este ejemplo se muestra cómo usar variables secretas $(vmsUser) y en una tarea de copia de archivos de $(vmsAdminPass) Azure.
variables:
VMS_USER: $(vmsUser)
VMS_PASS: $(vmsAdminPass)
pool:
vmImage: 'ubuntu-latest'
steps:
- task: AzureFileCopy@4
inputs:
SourcePath: 'my/path'
azureSubscription: 'my-subscription'
Destination: 'AzureVMs'
storage: 'my-storage'
resourceGroup: 'my-rg'
vmsAdminUserName: $(VMS_USER)
vmsAdminPassword: $(VMS_PASS)
Referencia a variables secretas en grupos de variables
En este ejemplo se muestra cómo hacer referencia a un grupo de variables en el archivo YAML y también agregar variables dentro de YAML. Hay dos variables usadas del grupo de variables: user y token . La variable es secreta y se asigna a la variable de entorno para que se pueda hacer token referencia a ella en EL ARCHIVO $env:MY_MAPPED_TOKEN YAML.
Este YAML realiza una llamada REST para recuperar una lista de versiones y genera el 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
De forma predeterminada GitHub repositorios, las variables secretas asociadas a la canalización no están disponibles para las compilaciones de solicitudes de extracción de bifurcaciones. Para obtener más información, vea Contribuciones de bifurcaciones.
YAML no se admite en TFS.
Compartir variables entre canalizaciones
Para compartir variables entre varias canalizaciones del proyecto, use la interfaz web. En Biblioteca ,use grupos de variables.
Uso de variables de salida de tareas
Algunas tareas definen variables de salida, que se pueden consumir en pasos, trabajos y fases de bajada. En YAML, puede acceder a variables entre trabajos y fases mediante dependencias.
Algunas tareas definen variables de salida, que se pueden consumir en pasos y trabajos de nivel inferior dentro de la misma fase. En YAML, puede acceder a variables entre trabajos mediante dependencias.
Algunas tareas definen variables de salida, que puede consumir en pasos de bajada dentro del mismo trabajo.
Nota:
De forma predeterminada, cada fase de una canalización depende de la que se encuentra justo antes de ella en el archivo YAML. Si necesita hacer referencia a una fase que no es inmediatamente anterior a la actual, puede invalidar este valor predeterminado automático agregando una sección a dependsOn la fase.
Nota:
En los ejemplos siguientes se usa la sintaxis de canalización estándar. Si usa canalizaciones de implementación, la sintaxis de variables y variables condicionales será diferente. Para obtener información sobre la sintaxis específica que se debe usar, vea Trabajos de implementación.
En estos ejemplos, suponga que tenemos una tarea denominada MyTask , que establece una variable de salida denominada MyVar .
Obtenga más información sobre la sintaxis en Expresiones: dependencias.
Uso de salidas en el mismo trabajo
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
Uso de salidas en un trabajo 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
Uso de salidas en una fase diferente
Para usar la salida de una fase diferente en el nivel de trabajo, use la stageDependencies sintaxis .
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
- 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
También puede pasar variables entre fases con una entrada de archivo. Para ello, deberá definir variables en la segunda fase en el nivel de trabajo y, a continuación, pasar las variables como env: entradas.
## 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)
La salida de las fases de la canalización anterior tiene el siguiente aspecto:
Hello inline version
true
crushed tomatoes
Enumerar variables
Puede enumerar todas las variables de la canalización con el comando az pipelines variable list. Para empezar, consulte Introducción a la CLI Azure DevOps.
az pipelines variable list [--org]
[--pipeline-id]
[--pipeline-name]
[--project]
Parámetros
- org: Azure DevOps url de la organización. Puede configurar la organización predeterminada mediante
az devops configure -d organization=ORG_URL. Obligatorio si no está configurado como predeterminado o se selecciona mediantegit config. Ejemplo:--org https://dev.azure.com/MyOrganizationName/. - pipeline-id:se requiere si no se proporciona pipeline-name. Identificador de la canalización.
- pipeline-name:se requiere si no se proporciona pipeline-id, pero se omite si se proporciona pipeline-id. Nombre de la canalización.
- project:nombre o identificador del proyecto. Puede configurar el proyecto predeterminado mediante
az devops configure -d project=NAME_OR_ID. Obligatorio si no está configurado como predeterminado o se selecciona mediantegit config.
Ejemplo
El comando siguiente enumera todas las variables de la canalización con el identificador 12 y muestra el resultado en formato de tabla.
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
Establecer variables en scripts
Un script de la canalización puede definir una variable para que pueda consumirla uno de los pasos posteriores de la canalización. Todas las variables establecidas por este método se tratan como cadenas. Para establecer una variable a partir de un script, use una sintaxis de comando e imprima en stdout.
Establecer una variable de ámbito de trabajo a partir de un script
Para establecer una variable a partir de un script, use el task.setvariabletask.setvariable. Esto actualizará las variables de entorno para los trabajos posteriores. Los trabajos posteriores tendrán acceso a la nueva variable con sintaxis de macro y en tareas como variables de entorno.
Cuando se establece en true, el valor de la variable se guardará issecret como secreto y se enmascarará del registro. Para obtener más información sobre las variables secretas,vea Comandos de registro .
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)
Los pasos posteriores también tendrán la variable de canalización agregada a su entorno. No se puede usar la variable en el paso que se define.
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"
Salida de la canalización anterior.
my environment variable is crushed tomatoes
my environment variable is crushed tomatoes
Establecer una variable de salida de varios trabajos
Si desea que una variable esté disponible para trabajos futuros, debe marcarla como una variable de salida mediante isOutput=true . A continuación, puede asignarlo a trabajos futuros mediante la $[] sintaxis e incluyendo el nombre de paso que establece la variable. Las variables de salida de varios trabajos solo funcionan para trabajos en la misma fase.
Para pasar variables a trabajos en distintas fases, use la sintaxis de dependencias de fase.
Nota:
De forma predeterminada, cada fase de una canalización depende de la que se encuentra justo antes de ella en el archivo YAML. Por lo tanto, cada fase puede usar variables de salida de la fase anterior. Para acceder a otras fases, deberá modificar el gráfico de dependencias; por ejemplo, si la fase 3 requiere una variable de la fase 1, deberá declarar una dependencia explícita en la fase 1.
Al crear una variable de salida de varios trabajos, debe asignar la expresión a una variable. En este YAML, $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] se asigna a la variable $(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-18.04'
variables:
myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] # map in the variable
# remember, expressions require single quotes
steps:
- script: echo $(myVarFromJobA)
name: echovar
Salida de la canalización anterior.
this is the value
this is the value
Si va a establecer una variable de una fase a otra, 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)
Si va a establecer una variable desde una matriz o un segmento ,para hacer referencia a la variable al acceder a ella desde un trabajo de bajada, debe incluir:
- Nombre del trabajo.
- Paso.
jobs:
# Set an output variable from a job with a matrix
- job: A
pool:
vmImage: 'ubuntu-18.04'
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-18.04'
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-18.04'
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-18.04'
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
steps:
- script: "echo $(myVarFromJobsA1)"
name: echovar
Asegúrese de antefijo el nombre del trabajo en las variables de salida de un trabajo de implementación. En este caso, el nombre del trabajo es A :
jobs:
# Set an output variable from a deployment
- deployment: A
pool:
vmImage: 'ubuntu-18.04'
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-18.04'
variables:
myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
steps:
- bash: "echo $(myVarFromDeploymentJob)"
name: echovar
YAML no se admite en TFS.
Establecer las 
Establecer las 
Establecer las Establecer variables mediante expresiones
Puede establecer una variable mediante una expresión. Ya se encontró un caso de esto para establecer una variable en la salida de otra de un trabajo anterior.
- job: B
dependsOn: A
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ] # remember to use single quotes
Puede usar cualquiera de las expresiones admitidas para establecer una variable. Este es un ejemplo de cómo establecer una variable para que actúe como un contador que comienza en 100, se incrementa en 1 para cada ejecución y se restablece a 100 cada día.
jobs:
- job:
variables:
a: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 100)]
steps:
- bash: echo $(a)
Para obtener más información sobre contadores, dependencias y otras expresiones, vea expresiones.
YAML no se admite en TFS.
Configuración de variables configurables para los pasos
Puede definir dentro settableVariables de un paso o especificar que no se pueda establecer ninguna variable.
En este ejemplo, el script no puede establecer una variable.
steps:
- script: echo This is a step
target:
settableVariables: none
En este ejemplo, el script permite la variable sauce , pero no la variable secretSauce . Verá una advertencia en la página de ejecución de la canalización.
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 en tiempo de cola
Si aparece una variable en el bloque de un archivo YAML, su valor es fijo y no se puede variables invalidar en tiempo de cola. El procedimiento recomendado es definir las variables en un archivo YAML, pero hay ocasiones en las que esto no tiene sentido. Por ejemplo, puede definir una variable secreta y no exponerla en el YAML. O bien, es posible que tenga que establecer manualmente un valor de variable durante la ejecución de la canalización.
Tiene dos opciones para definir valores en tiempo de cola. Puede definir una variable en la interfaz de usuario y seleccionar la opción Permitir a los usuarios invalidar este valor al ejecutar esta canalización o puede usar parámetros en tiempo de ejecución en su lugar. Si la variable no es un secreto, el procedimiento recomendado es usar parámetros en tiempo de ejecución.
Para establecer una variable en tiempo de cola, agregue una nueva variable dentro de la canalización y seleccione la opción de invalidación.
Para permitir que una variable se establezca en tiempo de cola, asegúrese de que la variable no aparezca también en el bloque variables de una canalización o un trabajo. Si define una variable en el bloque de variables de un YAML y en la interfaz de usuario, el valor de YAML tendrá prioridad.
YAML no se admite en TFS.
Expansión de variables
Al establecer una variable con el mismo nombre en varios ámbitos, se aplica la siguiente prioridad (prioridad más alta primero).
- Variable de nivel de trabajo establecida en el archivo YAML
- Variable de nivel de fase establecida en el archivo YAML
- Variable de nivel de canalización establecida en el archivo YAML
- Variable establecida en tiempo de cola
- Variable de canalización establecida en la interfaz de usuario de configuración de canalización
En el ejemplo siguiente, la misma variable se establece en el nivel de canalización y a el nivel de trabajo en el archivo YAML. También se establece en un grupo de variables y como una variable en la interfaz de usuario G configuración de canalización.
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'
Cuando se establece una variable con el mismo nombre en el mismo ámbito, el último valor establecido tendrá prioridad.
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:
Cuando establezca una variable en el archivo YAML, no la defina en el editor web como configurable en tiempo de cola. Actualmente no se pueden cambiar las variables establecidas en el archivo YAML en tiempo de cola. Si necesita establecer una variable en tiempo de cola, no la establezca en el archivo YAML.
Las variables se expanden una vez cuando se inicia la ejecución y de nuevo al principio de cada paso. Por ejemplo:
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
Hay dos pasos en el ejemplo anterior. La expansión de se produce una vez al principio del trabajo y una vez al $(a) principio de cada uno de los dos pasos.
Dado que las variables se expanden al principio de un trabajo, no se pueden usar en una estrategia. En el ejemplo siguiente, no se puede usar la variable para expandir la matriz de trabajos, porque la variable solo está disponible al principio a de cada trabajo expandido.
jobs:
- job: A
variables:
a: 10
strategy:
matrix:
x:
some_variable: $(a) # This does not work
Si la variable a es una variable de salida de un trabajo anterior, puede usarla en un trabajo 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'] ]
Expansión recursiva
En el agente, las variables a las que se hace referencia mediante la sintaxis $( ) se expanden de forma recursiva.
Por ejemplo:
variables:
myInner: someValue
myOuter: $(myInner)
steps:
- script: echo $(myOuter) # prints "someValue"
displayName: Variable is $(myOuter) # display name is "Variable is someValue"
YAML no se admite en TFS.