🥇Utilisation des variables dans les pipelines Azure DevOps

Nous continuons notre aperçu de l'excellent outil de développement pour Windows et plus encore, Azure DevOps. Cette fois, après avoir lutté avec les variables d'environnement, j'ai décidé de rassembler toute mon expérience dans un seul article.

À commencer par le fait qu'ils ont une syntaxe différente pour chaque environnement d'exécution, jusqu'à l'absence d'une possibilité standard de transférer des variables d'une étape de pipeline à une autre.

Je précise que les principaux exemples seront sur les pipelines de version, car le YAML n'est pas encore arrivé, et j'ai besoin de la fonctionnalité de plusieurs étapes et de nombreux artefacts. Cela semble désormais disponible dans les pipelines classiques, ce qui égalise presque leur fonctionnalité. Le YAML des pipelines a été amélioré et une petite aide graphique a été ajoutée à la représentation textuelle, avec les paramètres qui peuvent être définis. Très pratique, pas besoin de consulter la documentation pour chaque module. Mais je décrirai cela dans le prochain article, pour l'instant voici l'image de la nouveauté.

Stockage et utilisation

Commençons par le fait qu'il y a des variables par défaut dans le système. Elles commencent, selon leur origine, par les mots Release, System, etc. La liste complète (comme il s'est avéré, il n'y en a pas) est disponible chez documentation. Toute la confusion avec la syntaxe est illustrée par l'exemple de la documentation ci-dessous. Une même variable a trois représentations, selon l'endroit où nous l'appelons.

steps:
 - bash: echo Ce script pourrait utiliser $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Ceci est un script qui pourrait utiliser $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Si vous définissez une variable sur l'agent exécutant la tâche, c'est $(System.AccessToken). Si vous souhaitez l'utiliser dans un script powershell sur le même agent, ce sera déjà $env:SYSTEM_ACCESSTOKEN. Si vous, par malheur, souhaitez utiliser cette variable sur un hôte distant, en utilisant la tâche PowerShell sur des machines cibles, vous devez la transmettre en tant qu'argument au script, en utilisant param. Avec bash, c'est plus simple, vous pouvez simplement la passer en utilisant un argument et la syntaxe $SYSTEM_ACCESSTOKEN.

Les mêmes règles ne s'appliquent pas à vos propres variables, ici vous êtes responsable de la syntaxe. Les variables peuvent être définies localement dans chaque tâche.

Ou globalement dans le stockage de variables, puis les lier depuis le stockage. Très pratique.

En bonus, si les variables sont très sensibles, elles peuvent être stockées dans le cloud Azure dans un espace de stockage appelé Azure Vault, et le Vault peut être lié au projet dans la bibliothèque.

En général, les variables sont claires, dans les pipelines, elles peuvent également être définies manuellement à chaque lancement, mais cette fonctionnalité n'est pas disponible dans le release. Vous pouvez vérifier ce que vous passez dans le pipeline une fois de plus dans les journaux d'initialisation de l'agent, mais gardez à l'esprit qu'elles y sont déjà sous forme transformée.

Variables dynamiques

Les choses deviennent intéressantes lorsque nous voulons obtenir une certaine valeur à une étape et la transmettre à la suivante.

Cette fonctionnalité ne nous a pas été fournie. Mais nos mains ne sont pas faites pour s'ennuyer et grâce à Google, une solution a été trouvée. Dieu merci, Azure DevOps dispose d'une API qui nous permet de faire un peu plus que ce qui est dessiné dans l'interface.

Ainsi, nous aurons besoin d'un appel pour mettre à jour les variables globales, que nous ferons directement depuis le pipeline. L'adresse est tirée des variables d'environnement, celles dont il n'est pas fait mention dans la documentation, comme cela a été mentionné précédemment. Vous pouvez les définir vous-même ou, tant qu'à faire, les coder en dur, si ce service est fermé.

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

Nous définissons une valeur vide pour la variable que nous souhaitons transmettre, en définissant le Scope — Release

À titre d'exemple, nous créons un générateur de valeurs aléatoires. Notez la syntaxe de déclaration de la variable à l'intérieur de cette étape, cette fonctionnalité a été ajoutée.

À l'étape suivante, nous passons la variable au script, oui, oui, pas directement, il faut passer par un argument.

Script sous 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 ID de test : ${INPUT_VAR}

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

echo url de release : $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 deux mots, notre script prend en entrée la variable myVar et utilise l'API pour placer la valeur de cette variable dans stageVar. À l'étape suivante, en utilisant la syntaxe des variables système, nous pouvons la voir.

L'exemple est assez simple, mais la fonctionnalité nous ouvre de bonnes possibilités, en conjonction avec mon précédent article, lorsque nous pouvons créer une machine virtuelle lors de la première phase de test, effectuer certaines manipulations ensuite, et ce, en parallèle sur plusieurs d'entre elles. La phase finale consiste à la détruire. Actuellement, nous exécutons des tests automatisés du produit à chaque fois sur des machines virtuelles fraîches. Étant donné qu'elles ne vivent que dix minutes, cela ne coûte quasiment rien.

Dans l'article suivant, si besoin, je parlerai des pipelines YAML, il y a pas mal de nouveautés intéressantes dernièrement.

Source : habr.com

Dans l'application Timeshift, une vulnérabilité a été identifiée

Stockage et utilisation

Variables dynamiques