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 . 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 . 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))
#endregionVagy
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_URLRö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. , 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
