Korištenje varijabli u Azure DevOps pipelinama

Nastavljamo pregled sjajne alate za razvoj na Windowsu i ne samo to, Azure DevOps. Ovaj put, mučivši se s varijablama okruženja, odlučio sam svoja iskustva sažeti u jedan članak.

Počevši od toga da svaki izvršni okoliš ima drugačiju sintaksu, do nedostatka standardne mogućnosti prijenosa varijabli iz jedne faze cjevovoda u drugu.

Moram napomenuti da će glavni primjeri biti na Release Pipelines, jer YAML još nije stigao, a meni je potrebna funkcionalnost više faza i više artefakata. To je, čini se, postalo dostupno u običnim Pipelines, što ih je praktički izjednačilo po funkcionalnosti. U Pipelines su dodatno razvili YAML i dodali grafički savjet s parametrima koje možete postaviti na tekstualno predstavljanje. Vrlo praktično, nije potrebno kopati u dokumentaciju za svaki modul. Ali to ću opisivati u sljedećem članku, a sada ovdje je slika novog dodatka.

Skladištenje i upotreba

Počnimo od toga da u sustavu imamo varijable po defaultu. One počinju, ovisno o podrijetlu, riječima Release, System, itd. Potpun popis (kako se ispostavilo, ne postoji) dostupan je u dokumentaciju. Cjelokupna šizofrenija sa sintaksom ilustrira primjer iz dokumentacije u nastavku. Ista varijabla ima tri prikaza, ovisno o tome gdje je pozivamo.

steps:
 - bash: echo Ovaj skript bi mogao koristiti $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Ovo je skript koji bi mogao koristiti $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Ako definirate varijablu na agentu na kojem se izvršava zadatak, to je $(System.AccessToken). Ako je želite koristiti unutar PowerShell skripta na istom agentu, to će već biti $env:SYSTEM_ACCESSTOKEN. Ako, ne daj Bože, želite koristiti tu varijablu na nekom udaljenom hostu, koristeći PowerShell zadatak na ciljnim mašinama, trebate je prenijeti putem argumenta u skriptu, koristeći param. S bashom je to lakše, može se jednostavno proslijediti unutra koristeći argument i sintaksu $SYSTEM_ACCESSTOKEN.

Ista pravila se ne primjenjuju na vaše vlastite varijable, tu već preuzimate odgovornost za sintaksu. Varijable se mogu postaviti lokalno u svakom zadatku.

Ili globalno u skladištu varijabla, a zatim ih povezati iz skladišta. Vrlo korisno.

Kao bonus, ako su varijable jako tajne, mogu se pohraniti u Azure oblaku u skladištu nazvanom Azure Vault, a Vault se može povezati s projektom u Library.

Općenito, s varijablama je sve jasno, u pipelines ih još možemo postavljati ručno za svako pokretanje, u releaseu takva funkcionalnost ne postoji. Ono što ste prenijeli u pipeline možete ponovno vidjeti u zapisima inicijalizacije agenta, ali imajte na umu da su tamo već u promijenjenom obliku.

Dinamičke varijable

Najzanimljivije počinje kada želimo dobiti neku vrijednost u jednoj fazi i prenijeti je u sljedeću.

Takva funkcionalnost nam nije donesena. No, naše ruke nisu za dosadu i uz pomoć Googla pronašlo se rješenje. Hvala Bogu, Azure DevOps ima API koji nam omogućuje da napravimo malo više nego što je prikazano u sučelju.

Dakle, trebat će nam poziv za ažuriranje globalnih varijabli, koji ćemo napraviti izravno iz pipelinea. Adresa se uzima iz varijabla okruženja, tih istih o kojima nema ni riječi u dokumentaciji, kao što je ranije spomenuto. Možete ih sami postaviti ili, što da ne, he hardcodirati, ako zatvore radnju.

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

Postavljamo praznu vrijednost varijable koju želimo prenijeti, postavljamo Scope — Release.

Za primjer pravimo neki nasumični generator vrijednosti. Obratite pažnju na sintaksu deklaracije varijable unutar ove faze, takva funkcionalnost je dodana.

U sljedećoj fazi prenosimo varijablu skripti, da, da, ne može izravno, mora kroz argument.

Skripta pod špilerom

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

Ili

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

U dvije riječi, naša skripta uzima varijablu myVar kao ulaz i koristeći API postavlja vrijednost te varijable u stageVar. U sljedećoj fazi, koristeći sintaksu sistemskih varijabli, možemo je pogledati.

Primjer je prilično jednostavan, ali funkcionalnost nam otvara dobre mogućnosti, zajedno s mojom prošlom članak, kada možemo kreirati virtualnu mašinu u prvoj fazi testiranja, izvesti neke manipulacije s njom, i to istovremeno s nekoliko. A kao završni korak, uništiti je. Trenutno se automatski testovi proizvoda pokreću svaki put na svježim virtualnim mašinama. S obzirom na to da traju 10 minuta, to košta malo novca.

U sljedećem članku, ako bude potrebe, govorit ću o YAML pipelineima, tu ima dosta zanimljivih noviteta u zadnje vrijeme.

Izvor: habr.com