🥇Uso de variables en pipelines de Azure DevOps

Continuamos con la revisión de una magnífica herramienta de desarrollo para Windows y más, Azure DevOps. Esta vez, tras luchar con las variables de entorno, decidí recopilar toda la experiencia en un solo artículo.

Desde el hecho de que cada entorno de ejecución tiene su propia sintaxis, hasta la falta de una capacidad estándar para transferir variables de una etapa del pipeline a otra.

Aclaro que los ejemplos principales estarán en Release Pipelines, porque YAML aún no ha llegado allí, y necesito la funcionalidad de múltiples etapas y múltiples artefactos. Esto, al parecer, se ha vuelto accesible en los Pipelines normales, lo que prácticamente ha equiparado su funcionalidad. En los Pipelines YAML se han hecho mejoras y se ha añadido al formato de texto una pequeña sugerencia gráfica con los parámetros que se pueden definir. Muy conveniente, no es necesario consultar la documentación de cada módulo. Pero eso lo describiré en el siguiente artículo, por ahora aquí está la imagen de la nueva característica.

Almacenamiento y uso

Comencemos con el hecho de que en el sistema tenemos variables por defecto. Comienzan, dependiendo de su origen, con las palabras Release, System, etc. La lista completa (como resultó, no existe) está disponible en la documentación. Toda la confusión con la sintaxis se ilustra con el siguiente ejemplo de la documentación. La misma variable tiene tres representaciones, dependiendo de dónde la llamemos.

steps:
 - bash: echo Este script podría usar $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Este es un script que podría usar $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Si defines una variable en el agente donde se ejecuta la tarea, es $(System.AccessToken). Si deseas usarla dentro de un script de PowerShell en el mismo agente, ya será $env:SYSTEM_ACCESSTOKEN. Si, por algún motivo, deseas utilizar esta variable en algún host remoto, utilizando la tarea PowerShell en máquinas destino, necesitas pasarla como argumento al script, utilizando param. Con bash es más sencillo, puedes simplemente pasarlo usando el argumento y la sintaxis $SYSTEM_ACCESSTOKEN.

Las mismas reglas no se aplican a tus propias variables, aquí eres responsable de la sintaxis. Las variables se pueden definir localmente en cada tarea.

O globalmente en el almacenamiento de variables, y luego enlazarlas desde allí. Muy conveniente.

Como bono, si las variables son muy secretas, se pueden almacenar en la nube de Azure en un almacenamiento llamado Azure Vault, y se puede vincular Vault al proyecto en Library.

En general, las variables están claras, en pipelines se pueden establecer manualmente para cada ejecución, pero en el release no hay tal funcionalidad. Se puede ver lo que se pasa al pipeline una vez más en los registros de inicialización del agente, pero ten en cuenta que ya están en forma transformada.

Variables dinámicas

Lo más interesante comienza cuando queremos obtener un valor en un paso y pasarlo al siguiente.

No se nos proporcionó tal funcionalidad. Pero nuestras manos no son para estar quietas y encontramos una solución con ayuda de Google. Afortunadamente, Azure DevOps tiene una API que nos permite hacer un poco más de lo que se muestra en la interfaz.

Así que necesitaremos una llamada para actualizar variables globales, que haremos directamente desde el pipeline. La dirección se obtiene de las variables de entorno, esas de las que no hay mención en la documentación, como se mencionó anteriormente. Puedes definirlas tú mismo o, qué demonios, codificarlas, si se cierra la opción.

$releaseurl = ('{0}{1}\/apis\/release\/releases\/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID))

Asignamos un valor vacío a la variable que queremos pasar, establecemos Scope — Release.

Por ejemplo, hacemos un generador de valores aleatorios. Nota el sintaxis de declaración de la variable dentro de este paso, tal funcionalidad fue añadida.

En el siguiente paso pasamos la variable al script, sí, no se puede de forma directa, tiene que ser a través de un argumento.

Script bajo spoiler

PowerShell

#Script requires stageVar variable in release variables set to Release scope

param ( [string] $expVar )
#region variables
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )
#endregion


#region Get Release Definition
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output current Release Pipeline
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion


#region Update StageVar with new value
$release.variables.($ReleaseVariableName).value = "$expVar"
#endregion

#region update release pipeline
Write-Output ('Updating Release Definition')
$json = @($release) | ConvertTo-Json -Depth 99
Invoke-RestMethod -Uri $releaseurl -Method Put -Body $json -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
#endregion

#region Get updated Release Definition
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output Updated Release Pipeline
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion

Bash

INPUT_VAR=$1
RELEASE_VAR=$2

echo Test ID: ${INPUT_VAR}

RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}\/apis\/release\/releases\/${RELEASE_RELEASEID}?api-version=5.0"

echo release url: $RELEASE_URL

RELEASE_JSON=$(curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" $RELEASE_URL)

OUTPUT=`jq ''.variables.${RELEASE_VAR}.value' = '"${INPUT_VAR}"'' <<< $RELEASE_JSON`

curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" -H "Content-Type: application\/json" -X PUT -d "$OUTPUT" $RELEASE_URL

En pocas palabras, nuestro script toma como entrada la variable myVar y usando la API asigna el valor de esa variable a stageVar. En el siguiente paso, usando la sintaxis de variables del sistema, podemos verla.

El ejemplo es bastante simple, pero la funcionalidad nos ofrece buenas oportunidades, sumado a mi experiencia anterior. artículo, cuando podemos crear una máquina virtual en la primera etapa de prueba, realizar algunas manipulaciones con ella posteriormente, incluso varias en paralelo. Y como etapa final, eliminarla. Actualmente, estamos ejecutando pruebas automáticas del producto cada vez en máquinas virtuales nuevas. Dado que viven unos 10 minutos, esto cuesta muy poco.

En el próximo artículo, si hay necesidad, hablaré sobre los pipelines YAML, donde ha habido bastantes novedades interesantes últimamente.

Fuente: habr.com

Uso de variables en los pipelines de Azure DevOps

Almacenamiento y uso

Variables dinámicas