🥇Mainīgo izmantošana Azure DevOps cauruļvados

Mēs turpinām pārskatīt brīnišķīgu Windows un citu izstrādes rīku Azure DevOps. Šoreiz, daudz cietis ar vides mainīgajiem, nolēmu visu pieredzi salikt vienā rakstā.

Sākot ar to, ka tiem ir atšķirīga sintakse katrai izpildes videi, beidzot ar standarta iespēju trūkumu pārsūtīt mainīgos no viena konveijera posma uz citu.

Es izdarīšu atrunu, ka galvenie piemēri būs izlaiduma cauruļvados, jo YAML vēl nav nokļuvis tur, un man ir nepieciešama daudzu posmu funkcionalitāte un daudzi artefakti. Šķiet, ka tas ir kļuvis pieejams parastajos cauruļvados, kas praktiski tiem līdzinās funkcionalitātē. Programmā Pipelines YAML teksta attēlojumam pievienojām nelielu grafisku rīka padomu ar parametriem, kurus var iestatīt. Tas ir ļoti ērti; jums nav jāiet cauri katra moduļa dokumentācijai. Bet to es aprakstīšu nākamajā rakstā, bet pagaidām šeit ir bilde par pašu jauninājumu.

Uzglabāšana un lietošana

Sāksim ar to, ka mums sistēmā ir noklusējuma mainīgie. Tie sākas atkarībā no to izcelsmes ar vārdiem Release, System utt. Pilns saraksts (kā izrādās, ne) ir pieejams vietnē dokumentācija. Visas šizofrēnijas ar sintaksi ir ilustrētas ar piemēru no tālāk esošās dokumentācijas. Tam pašam mainīgajam ir trīs attēlojumi atkarībā no tā, kur mēs to saucam.

steps:
 - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Ja aģentam, kuram uzdevums tiek izpildīts, iestatāt mainīgo, tas ir $(System.AccessToken). Ja vēlaties to izmantot powershell skriptā tajā pašā aģentā, tas jau būs $env:SYSTEM_ACCESSTOKEN. Ja jūs, nedod Dievs, vēlaties izmantot šo mainīgo kādā attālā resursdatorā, izmantojot PowerShell uzdevumu mērķa mašīnās, jums tas ir jānodod ar argumentu skriptam, izmantojot mana nauda. Izmantojot bash, tas ir vienkāršāk, to var vienkārši nodot iekšā, izmantojot argumentu un sintaksi $SYSTEM_ACCESSTOKEN.

Tie paši likumi neattiecas uz jūsu mainīgajiem, šeit jūs jau esat atbildīgs par sintaksi. Mainīgos var iestatīt lokāli katrā uzdevumā.

Vai globāli uz mainīgo veikalu un pēc tam saistīt tos no veikala. Ļoti ērti.

Kā bonusu, ja mainīgie ir ļoti slepeni, tos var glabāt Azure mākonī krātuvē ar nosaukumu Azure Vault; varat saistīt Vault ar projektu bibliotēkā.

Kopumā ar mainīgajiem lielumiem viss ir skaidrs; cauruļvados tos joprojām var iestatīt manuāli katrai palaišanai; izlaidumā šādas funkcionalitātes nav. To, ko pārsūtāt uz konveijeru, atkal varat redzēt aģenta inicializācijas žurnālos, taču ņemiet vērā, ka tie jau ir tur konvertētā veidā.

Dinamiskie mainīgie

Jautrība sākas, kad mēs vēlamies saņemt kādu vērtību vienā posmā un nodot to nākamajā.

Tāda funkcionalitāte mums netika nodrošināta. Taču mūsu rokas nav priekš garlaicības un ar Google palīdzību tika atrasts risinājums. Paldies Dievam, Azure DevOps ir API, kas ļauj mums paveikt nedaudz vairāk, nekā tika attēlots saskarnē.

Tātad mums būs nepieciešams aicinājums atjaunināt globālos mainīgos, ko mēs darīsim tieši no konveijera. Adrese tiek ņemta no vides mainīgajiem, tiem pašiem, par kuriem dokumentācijā nav ne vārda, kā minēts iepriekš. Varat tos iestatīt pats vai, vēl jo vairāk, iekodēt, ja veikals tiek slēgts.

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

Mēs iestatām tukšo mainīgā vērtību, kuru vēlamies pārsūtīt, iestatiet Scope - Release

Piemēram, mēs izveidojam nejaušu vērtību ģeneratoru. Šajā posmā pievērsiet uzmanību mainīgā deklarēšanas sintaksei; šī funkcionalitāte tika ieviesta.

Nākamajā solī mainīgo nododam skriptam, jā, jā, tas nav iespējams tieši, tam ir jābūt ar argumenta palīdzību.

Skripts zem spoilera

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

Vai

Stipri iesist

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

Īsāk sakot, mūsu skripts izmanto mainīgo myVar kā ievadi un izmanto API, lai šī mainīgā vērtību ievietotu stageVar. Nākamajā solī, izmantojot sistēmas mainīgā sintaksi, mēs varam to apskatīt.

Piemērs ir diezgan vienkāršs, bet funkcionalitāte mums paver labas iespējas, papildus manai iepriekšējai rakstus, kad mēs varam izveidot virtuālo mašīnu pirmajā testēšanas posmā, veikt ar to dažas turpmākas manipulācijas un vairākas paralēli. Un pēdējais posms ir to iznīcināt. Tagad mēs katru reizi veicam produkta automātiskos testus jaunās virtuālās mašīnās. Ņemot vērā, ka viņi dzīvo apmēram 10 minūtes, tas maksā santīmu.

Nākamajā rakstā, ja vajadzēs, runāšu par YAML cauruļvadiem, tur pēdējā laikā ir bijis diezgan daudz interesantu jauninājumu.

Avots: www.habr.com

Mainīgo izmantošana Azure DevOps konveijeros

Uzglabāšana un lietošana

Dinamiskie mainīgie

Pievieno komentāru Atcelt atbildi