Nastavljamo s pregledom prekrasnog alata za razvoj za Windows i više, Azure DevOps. Ovaj put, nakon što sam se dosta mučio s varijablama okruženja, odlučio sam svo iskustvo staviti u jedan članak.
Počevši od činjenice da imaju različitu sintaksu za svako izvršno okruženje, završavajući nedostatkom standardne mogućnosti prijenosa varijabli iz jedne faze cjevovoda u drugu.
Napravit ću rezervu da će glavni primjeri biti na Release Pipelines, jer YAML još nije stigao tamo, a trebam funkcionalnost mnogih faza i mnogo artefakata. Ovo je, čini se, postalo dostupno u regularnim Pipelinesima, što im je praktički jednako u funkcionalnosti. U Pipelines YAML, dodali smo mali grafički alatni opis tekstualnom prikazu s parametrima koji se mogu postaviti. Vrlo je zgodno; ne morate prolaziti kroz dokumentaciju za svaki modul. Ali to ću opisati u sljedećem članku, ali za sada je ovdje slika same inovacije.
Skladištenje i uporaba
Počnimo s činjenicom da imamo zadane varijable u sustavu. Počinju, ovisno o podrijetlu, riječima Release, System itd. Potpuni popis (kako se ispostavilo, ne) dostupan je na . Sva shizofrenija sa sintaksom ilustrirana je primjerom iz dokumentacije u nastavku. Ista varijabla ima tri reprezentacije, ovisno o tome gdje je zovemo.
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)Ako postavite varijablu na agentu na kojem se zadatak izvršava, to je $(System.AccessToken). Ako ga želite koristiti unutar powershell skripte na istom agentu, to će već biti $env:SYSTEM_ACCESSTOKEN. Ako vi, ne daj Bože, želite koristiti ovu varijablu na nekom udaljenom hostu koristeći zadatak PowerShell na ciljnim strojevima, morate to proslijediti kroz argument skripti koristeći . S bashom je jednostavnije, možete ga jednostavno proslijediti unutra koristeći argument i sintaksu $SYSTEM_ACCESSTOKEN.
Isti zakoni ne vrijede za vaše vlastite varijable; ovdje ste već odgovorni za sintaksu. Varijable se mogu postaviti lokalno u svakom zadatku.
Ili globalno na pohranu varijabli, a zatim ih povežite iz pohrane. Vrlo udobno.
Kao bonus, ako su varijable vrlo tajne, mogu se pohraniti u Azure oblak u pohranu koja se zove Azure Vault; možete povezati Vault s projektom u biblioteci.
Općenito, sve je jasno s varijablama; u cjevovodima se još uvijek mogu postaviti ručno za svako pokretanje; u izdanju nema takve funkcije. Možete ponovno vidjeti što prenosite u cjevovod u zapisnicima inicijalizacije agenta, ali imajte na umu da su oni već tamo u pretvorenom obliku.
Dinamičke varijable
Zabava počinje kada želimo primiti neku vrijednost u jednoj fazi i prenijeti je na drugu.
Nismo dobili takvu funkcionalnost. Ali naše ruke nisu za dosadu i uz pomoć Googlea pronađeno je rješenje. Hvala Bogu, Azure DevOps ima API koji nam omogućuje da radimo malo više od onoga što je prikazano u sučelju.
Dakle, trebat će nam poziv za ažuriranje globalnih varijabli, što ćemo učiniti izravno iz cjevovoda. Adresa je preuzeta iz varijabli okruženja, istih onih o kojima nema ni riječi u dokumentaciji, kao što je ranije spomenuto. Možete ih postaviti sami ili, štoviše, kodirati ako zatvore trgovinu.
$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
Na primjer, napravimo neki generator slučajnih vrijednosti. Obratite pozornost na sintaksu deklariranja varijable unutar ove faze; ova je funkcionalnost uvedena.
U sljedećem koraku prosljeđujemo varijablu skripti, da, da, to nije moguće izravno, mora biti kroz argument.
Skripta ispod spojlera
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))
#endregionili
Tresnuti
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_URLUkratko, naša skripta uzima varijablu myVar kao ulaz i koristi API za stavljanje vrijednosti ove varijable u stageVar. U sljedećem koraku, koristeći sintaksu sistemske varijable, možemo to pogledati.
Primjer je prilično jednostavan, ali funkcionalnost nam otvara dobre mogućnosti, uz moje prethodne , kada možemo stvoriti virtualni stroj u prvoj fazi testiranja, izvršiti neke daljnje manipulacije s njim, i nekoliko paralelno. A posljednja faza je uništiti ga. Sada pokrećemo autotestove proizvoda svaki put na novim virtualnim strojevima. S obzirom na to da žive oko 10 minuta, koštaju lipe.
U sljedećem članku, ako bude potrebno, govorit ću o YAML cjevovodima, tamo je u posljednje vrijeme bilo dosta zanimljivih inovacija.
Izvor: www.habr.com