🥇Utilizarea variabilelor în fluxurile de lucru Azure DevOps

Continuăm recenzia acestui instrument minunat pentru dezvoltare pe Windows și nu numai, Azure DevOps. De această dată, după multe încercări cu variabilele de mediu, am decis să sintetizez toată experiența într-un articol.

Începând cu faptul că pentru fiecare mediu de execuție au un sintax diferit, terminând cu lipsa unei opțiuni standard de transfer a variabilelor dintr-o etapă de pipeline în alta.

Menționez că exemplele principale vor fi pe Release Pipelines, deoarece YAML încă nu a ajuns acolo, iar eu am nevoie de funcționalitatea mai multor etape și de mai multe artefacte. Se pare că acest lucru a devenit disponibil în pipeline-urile obișnuite, ceea ce le-a egalat practic în funcționalitate. În Pipelines, YAML a fost îmbunătățit și s-a adăugat, pe lângă reprezentarea textuală, un mic ghid grafic cu parametrii care pot fi specificați. Foarte convenabil, nu trebuie să caut în documentația fiecărui modul. Dar despre asta voi scrie în articolul următor, iar acum iată o imagine a celei mai recente inovații.

Stocarea și utilizarea

Să începem cu faptul că în sistem avem variabile implicite. Acestea încep, în funcție de sursă, cu cuvintele Release, System, etc. Lista completă (după cum s-a dovedit, nu există) este disponibilă în documentation. Întreaga schizofrenie cu sintaxa este ilustrată printr-un exemplu din documentația de mai jos. Aceeași variabilă are trei reprezentări, în funcție de locul în care o apelăm.

steps:
 - bash: echo Acest script ar putea folosi $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Acesta este un script care ar putea folosi $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Dacă setați o variabilă pe agentul care execută task-ul, aceasta este $(System.AccessToken). Dacă doriți să o utilizați în interiorul unui script PowerShell pe același agent, aceasta va fi deja $env:SYSTEM_ACCESSTOKEN. Dacă, Doamne ferește, doriți să utilizați această variabilă pe un host remote, utilizând sarcina PowerShell pe mașinile țintă, va trebui să o transmiteți printr-un argument către script, folosind param. Cu bash este mai simplu, puteți pur și simplu să o transmiteți în interior folosind argumentul și sintaxa $SYSTEM_ACCESSTOKEN.

Aceleași reguli nu se aplică variabilelor proprii, aici sunteți responsabil pentru sintaxă. Puteți seta variabile local în fiecare sarcină.

Sau global în depozitul de variabile, apoi le puteți linka din depozit. Foarte convenabil.

Ca bonus, dacă variabilele sunt foarte secrete, le putem stoca în Azure Cloud într-un depozit numit Azure Vault, iar Vault-ul poate fi legat de proiect în Library.

În general, este clar ce sunt variabilele, în pipelines le putem defini manual pentru fiecare execuție, dar în release această funcționalitate nu există. Ce transmiteți în pipeline poate fi revizuit din nou în jurnalele de inițializare a agentului, dar rețineți că acolo sunt deja într-o formă transformată.

Variabile dinamice

Cel mai interesant începe atunci când dorim să obținem o anumită valoare într-o etapă și să o transmitem în următoarea.

Această funcționalitate nu a fost livrată. Dar mâinile noastre nu sunt pentru plictiseală și cu ajutorul Google am găsit o soluție. Slavă Domnului, Azure DevOps are API-ul care ne permite să facem puțin mai mult decât este ilustrat în interfață.

Așadar, avem nevoie de un apel pentru actualizarea variabilelor globale, pe care îl vom face direct din interiorul pipeline-ului. Adresa se obține din variabilele de mediu, despre care nu se menționează nimic în documentație, așa cum s-a menționat anterior. Le puteți defini singuri sau, de ce nu, să le hardcodificați, dacă ușa se va închide.

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

Setăm o valoare goală pentru variabila pe care dorim să o transmitem, stabilind Scope — Release.

De exemplu, creăm un generator de valori random. Observați sintaxa declarării variabilei în cadrul acestei etape, această funcționalitate a fost livrată.

În etapa următoare, transmitem variabila scriptului, da, da, nu se poate direct, trebuie prin argument.

Scriptul este sub 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 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

Pe scurt, scriptul nostru ia ca intrare variabila myVar și folosind API-ul pune valoarea acelei variabile în stageVar. În etapa următoare, folosind sintaxa variabilelor de sistem, o putem verifica.

Exemplul este destul de simplu, dar funcționalitatea ne deschide oportunități excelente, combinată cu ceea ce am avut anterior. articol, când putem crea o mașină virtuală în prima etapă a testării, să realizăm unele manipulări cu aceasta mai departe, chiar și mai multe în paralel. Iar etapa finală este distrugerea ei. Acum, avem teste automate ale produsului care sunt rulate de fiecare dată pe mașini virtuale proaspete. Având în vedere că acestea trăiesc timp de 10 minute, costul este infim.

În articolul următor, dacă va fi necesar, voi vorbi despre fluxurile de lucru YAML, acolo fiind destul de multe inovații interesante în ultima vreme.

Sursa: habr.com

Utilizarea variabilelor în pipeline-urile Azure DevOps

Stocarea și utilizarea

Variabile dinamice