Nadaljujemo s pregledom čudovitega orodja za razvoj za Windows in več, Azure DevOps. Tokrat, ko sem se veliko mučil s spremenljivkami okolja, sem se odločil vse izkušnje strniti v en članek.
Začenši z dejstvom, da imajo drugačno sintakso za vsako izvajalno okolje, konča s pomanjkanjem standardne zmožnosti prenosa spremenljivk iz ene stopnje cevovoda v drugo.
Pridržal se bom, da bodo glavni primeri na Release Pipelines, ker YAML še ni prišel tja in potrebujem funkcionalnost številnih stopenj in veliko artefaktov. Zdi se, da je to postalo na voljo v običajnih cevovodih, ki so praktično enaki po funkcionalnosti. V Pipelines YAML smo besedilni predstavitvi dodali majhen grafični opis orodja s parametri, ki jih je mogoče nastaviti. To je zelo priročno; ni vam treba pregledati dokumentacije za vsak modul. A to bom opisal v naslednjem članku, za zdaj pa je tukaj slika same inovacije.
Shranjevanje in uporaba
Začnimo z dejstvom, da imamo v sistemu privzete spremenljivke. Začnejo se, odvisno od izvora, z besedami Release, System itd. Celoten seznam (kot se je izkazalo, ne) je na voljo na . Vsa shizofrenija s sintakso je ponazorjena s primerom iz spodnje dokumentacije. Ista spremenljivka ima tri predstavitve, odvisno od tega, kje jo imenujemo.
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)Če na agentu, na katerem se izvaja naloga, nastavite spremenljivko, je to $(System.AccessToken). Če ga želite uporabiti znotraj skripta lupine powershell na istem agentu, bo že $env:SYSTEM_ACCESSTOKEN. Če želite, bog ne daj, uporabiti to spremenljivko na nekem oddaljenem gostitelju, ki uporablja nalogo PowerShell na ciljnih strojih, morate to prenesti skozi argument v skript z uporabo . Z bashom je preprostejši, lahko ga preprosto posredujete notri z uporabo argumenta in sintakse $SYSTEM_ACCESSTOKEN.
Enaki zakoni ne veljajo za vaše lastne spremenljivke; tu ste že odgovorni za sintakso. Spremenljivke lahko nastavite lokalno v vsaki nalogi.
Ali globalno v shrambo spremenljivk in jih nato povežite iz shrambe. Zelo udobno.
Kot bonus, če so spremenljivke zelo skrivne, jih je mogoče shraniti v oblaku Azure v shrambo, imenovano Azure Vault; Vault lahko povežete s projektom v knjižnici.
Na splošno je s spremenljivkami vse jasno, v cevovodih jih je še vedno mogoče nastaviti ročno za vsak zagon, v izdaji te funkcije ni. Kaj prenašate v cevovod, lahko znova vidite v dnevnikih inicializacije agenta, vendar ne pozabite, da so že tam v pretvorjeni obliki.
Dinamične spremenljivke
Zabava se začne, ko želimo neko vrednost prejeti v eni fazi in jo prenesti na naslednjo.
Takšne funkcionalnosti nam niso bile na voljo. A naše roke niso za dolgčas in s pomočjo Googla se je našla rešitev. Hvala bogu ima Azure DevOps API, ki nam omogoča, da naredimo malo več od tistega, kar je prikazano v vmesniku.
Torej bomo potrebovali klic za posodobitev globalnih spremenljivk, kar bomo naredili neposredno iz cevovoda. Naslov je vzet iz spremenljivk okolja, istih tistih, o katerih v dokumentaciji ni niti besede, kot je bilo omenjeno prej. Lahko jih nastavite sami ali, kar je več, strojno kodirate, če zaprejo trgovino.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Nastavimo prazno vrednost spremenljivke, ki jo želimo prenesti, nastavimo Scope - Release
Na primer, naredimo generator naključnih vrednosti. Bodite pozorni na sintakso deklaracije spremenljivke znotraj te stopnje; ta funkcionalnost je bila uvedena.
V naslednjem koraku posredujemo spremenljivko skriptu, ja, ja, to ni mogoče neposredno, to mora biti prek argumenta.
Scenarij pod spojlerjem
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))
#endregionOr
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_URLNa kratko, naš skript vzame spremenljivko myVar kot vhod in uporabi API, da vrednost te spremenljivke vnese v stageVar. V naslednjem koraku si ga lahko ogledamo s sintakso sistemske spremenljivke.
Primer je precej preprost, a funkcionalnost nam poleg mojih prejšnjih odpira dobre priložnosti , ko lahko na prvi stopnji testiranja ustvarimo virtualni stroj, izvedemo nekaj nadaljnjih manipulacij z njim in več vzporedno. In zadnja faza je uničenje. Zdaj izvajamo samodejne teste izdelka vsakič na svežih virtualnih strojih. Glede na to, da živijo približno 10 minut, stane peni.
V naslednjem članku, če bo potrebno, bom govoril o cevovodih YAML, tam je bilo v zadnjem času kar nekaj zanimivih novosti.
Vir: www.habr.com