🥇Változók használata az Azure DevOps pipeline-okban

Folytatjuk a Windows és más platformok fejlesztéséhez készült csodálatos eszköz, az Azure DevOps áttekintését. Ezúttal, miután sokat szenvedtem a környezeti változókkal, úgy döntöttem, hogy az összes tapasztalatomat egy cikkbe foglalom.

Kezdve azzal, hogy minden végrehajtási környezetnek eltérő szintaxisa van, egészen addig, hogy nincs standard lehetőség a változók áthelyezésére a folyamat egyik szakaszából a másikba.

Megjegyzem, hogy a fő példák a Release Pipeline-eken lesznek, mivel a YAML még nem érkezett meg oda, nekem pedig szükségem van több szakaszra és több artefaktra. Úgy tűnik, ez már elérhető a normál Pipelines-en, ami gyakorlatilag égalította a funkcionalitásukat. A YAML Pipelines-t finomították, és a szöveges megjelenítéshez hozzáadtak egy kis grafikus súgót a megadható paraméterekkel. Nagyon kényelmes, nem kell minden modul dokumentációjába bepillantanom. De ezt a következő cikkben fogom ismertetni, addig is itt van a legújabb újítás képe.

Tárolás és használat

Kezdjük azzal, hogy a rendszerben van egy alapértelmezett változó. Ezek az eredetüktől függően Release, System stb. szavakkal kezdődnek. A teljes lista (mint kiderült, nincs) elérhető a dokumentáció. Az alábbi példa a dokumentációból illusztrálja a szintaxis teljes zűrzavarát. Ugyanannak a változónak három megjelenítése van, attól függően, hogy hol hívjuk meg.

steps:
 - bash: echo Ez a script használhatja a $SYSTEM_ACCESSTOKEN-t
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Ez egy script, amely használhatja a $env:SYSTEM_ACCESSTOKEN-t"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Ha egy változót az ügynökön ad meg, ahol a feladat végrehajtódik, akkor az $(System.AccessToken). Ha ezt a PowerShell scriptben szeretné használni ugyanazon az ügynökön, akkor ez már a $env:SYSTEM_ACCESSTOKEN lesz. Ha, isten óvjon, ezt a változót egy távoli gépen akarja használni, a PowerShell on target machines feladattal, akkor ezt át kell adnia a script argumentumaként, használva param. A bash egyszerűbb, egyszerűen átadhatja az argumentumot és a $SYSTEM_ACCESSTOKEN szintaxist.

Ugyanezek a szabályok nem vonatkoznak a saját változóira, itt már Ön felelős a szintaxisért. Változókat helyben is megadhat, minden feladatban.

Vagy globálisan a változók tárolójában, majd onnan hivatkozhat rájuk. Nagyon kényelmes.

Ehhez bónuszként, ha a változók túl titkosak, az Azure felhőben tárolhatóak az Azure Vault néven ismert tárolóban, amelyet a Libraryban lehet csatlakoztatni a projekthez.

Összességében a változók világosak, a pipelines-ben kézzel is megadhatóak minden egyes futtatásra, de a kiadáskor nincs ilyen funkció. A pipeline-ba küldött értékeket újra meg lehet nézni az ügynök inicializálási naplójában, de figyelembe kell venni, hogy ezek már átalakított formában vannak ott.

Dinamikus változók

A legérdekesebb akkor kezdődik, amikor szeretnénk egy értéket kapni egy lépésben, és azt továbbítani a következőbe.

Ilyen funkciót nem biztosítottak nekünk. De a kezeink nem lusták, és a Google segítségével találtunk megoldást. Hála az Azure DevOps API-jának, amely lehetővé teszi számunkra, hogy kicsit többet tegyünk, mint amit a felületen megrajzoltak.

Tehát szükségünk lesz a globális változók frissítésére vonatkozó hívásra, amelyet közvetlenül a pipeline-ból fogunk végrehajtani. A cím a környezeti változókból származik, amelyeket korábban említettek, és amelyekről a dokumentációban szó sincs. Ezeket magad is megadhatod, vagy, ha szükséges, keményen kódolhatod, ha a dolgot leállítják.

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

Megadunk egy üres változó értéket, amelyet továbbítani szeretnénk, és beállítjuk a Scope-ot — Release.

Példaként készítünk egy véletlenszám-generátort. Figyelj a változó belső deklarálásának szintaxisára, ezt a funkciót bevezették.

A következő lépésben a változót átadjuk a szkriptnek, igen, közvetlenül nem lehet, csak úgy, hogy argumentumként adjuk át.

A szkript spoiler alatt

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

Vagy

Bash

INPUT_VAR=$1
RELEASE_VAR=$2

echo Teszt ID: ${INPUT_VAR}

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

echo kiadási 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

Röviden, a szkriptünk a myVar változót veszi bemeneti paraméterként, és az API-t használva elhelyezi ezen változó értékét a stageVar-ba. A következő lépésben, a rendszer változóinak szintaxisát használva, megnézhetjük.

A példa meglehetősen egyszerű, de a funkciók jó lehetőségeket nyitnak számunkra, a múlt kondíciómmal együtt. cikket, amikor létrehozhatunk egy virtuális gépet a tesztelés első szakaszában, és különböző manipulációkat hajthatunk végre rajta, ráadásul párhuzamosan több virtuális gép esetén is. A végső lépésként pedig megsemmisítjük azt. Jelenleg a termék automatikus tesztjei minden alkalommal friss virtuális gépeken futnak. Figyelembe véve, hogy ezek csak 10 percig élnek, ez fillérekbe kerül.

A következő cikkben, ha szükséges, mesélek a YAML pipeline-okról, ott az utóbbi időben rengeteg érdekes újdonság jelent meg.

Forrás: habr.com