Get best of the week

Uso de variables en canalizaciones de Azure DevOps

Continuamos revisando la maravillosa herramienta de desarrollo para Windows y no solo Azure DevOps. Esta vez, atormentado con variables de entorno, decidí poner toda la experiencia en un artículo.

Comenzando por el hecho de que para cada entorno de tiempo de ejecución tienen una sintaxis diferente, terminando con la falta de una capacidad estándar para transferir variables de una etapa de la tubería a otra.

Haré una reserva de que los ejemplos principales estarán en Release Pipelines, porque YAML aún no lo ha alcanzado, y necesito la funcionalidad de muchas etapas y muchos artefactos. Esto, al parecer, estuvo disponible en Pipelines regulares, que prácticamente los nivelaron en funcionalidad. En Pipelines, YAML agregó y agregó a la vista de texto una pequeña información sobre herramientas gráficas con parámetros que se pueden configurar. Muy conveniente, no es necesario entrar en la documentación de cada módulo. Pero describiré esto en el próximo artículo, pero por ahora, aquí hay una imagen de la innovación en sí.



Almacenamiento y uso


Para empezar, tenemos variables predeterminadas en el sistema. Comienzan, según el origen, con las palabras Liberación, Sistema, etc. Una lista completa (como resultó, no) está disponible en la documentación . Toda la esquizofrenia con sintaxis se ilustra con un ejemplo de la documentación a continuación. La misma variable tiene tres representaciones, dependiendo de dónde la llamemos.

steps:
 - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Si establece una variable en el agente que está ejecutando la tarea, esta es $ (System.AccessToken). Si desea usarlo dentro de un script de PowerShell en el mismo agente, ya será $ env: SYSTEM_ACCESSTOKEN. Si, Dios no lo quiera, desea utilizar esta variable en algún host remoto utilizando la tarea PowerShell en máquinas de destino, debe pasar esto a través del argumento del script utilizando param . Con bash más simple, puede lanzarlo usando el argumento y la sintaxis $ SYSTEM_ACCESSTOKEN.

Las mismas leyes no se aplican a sus propias variables, aquí ya es responsable de la sintaxis. Puede establecer variables localmente en cada tarea.



O globalmente en el repositorio de variables, y luego vincúlelas desde el repositorio. Muy confortablemente.



Como beneficio adicional de esto, si las variables son muy secretas, se pueden almacenar en la nube de Azure en un almacenamiento llamado Azure Vault, Vault se puede vincular al proyecto en la Biblioteca.



En general, todo está claro con las variables, en las tuberías aún puede configurarlas manualmente para cada lanzamiento, en la versión no existe tal funcionalidad. Puede ver lo que transfiere a la canalización nuevamente en los registros de inicialización del agente, pero tenga en cuenta que ya están en la forma convertida allí.



Variables dinámicas


La parte más interesante comienza cuando queremos obtener algo de valor en una etapa y pasarlo a la siguiente.



Dicha funcionalidad no nos fue entregada. Pero nuestras manos no son para aburrirse y con la ayuda de Google se encontró una solución. Gracias a Dios, Azure DevOps tiene una API que nos permite hacer un poco más de lo que dibujamos en la interfaz.

Por lo tanto, necesitamos una llamada para actualizar las variables globales, lo que haremos desde el interior de la tubería. La dirección se toma de variables de entorno, la misma de las cuales no hay una palabra en la documentación, como se mencionó anteriormente. Puede preguntarles usted mismo o, qué hay, codificar si cierran la tienda.

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

Establezca el valor vacío de la variable que queremos pasar, establezca Scope - Release.



Por ejemplo, hacemos un generador aleatorio de valores. Preste atención a la sintaxis de la declaración de variables dentro de esta etapa, se introdujo dicha funcionalidad.



En el siguiente paso, pasamos la variable al script, sí, sí, es imposible directamente, es necesario a través del argumento.



El guión bajo el spoiler

Powerhell
#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


O

Golpetazo
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 la variable de entrada myVar y el uso de la API pone el valor de esta variable en stageVar. En el siguiente paso, usando la sintaxis de las variables del sistema, podemos verlo.



El ejemplo es bastante simple, pero la funcionalidad nos ofrece buenas oportunidades, en total con mi último artículo , cuando podemos crear una máquina virtual en la primera etapa de prueba, hacer algunas manipulaciones adicionales y, al mismo tiempo, varias. Y el último paso es destruirlo. Ahora estamos persiguiendo autoevaluaciones de productos cada vez en máquinas virtuales nuevas. Dado que viven 10 minutos, vale un centavo.

En el siguiente artículo, si es necesario, hablaré sobre las tuberías de YAML, últimamente hay muchas innovaciones interesantes.

More articles:


All Articles