Pokračujeme v naší recenzi skvělého nástroje pro vývoj pro Windows a další, Azure DevOps. Tentokrát, protože jsem hodně trpěl na proměnné prostředí, rozhodl jsem se dát všechny zkušenosti do jednoho článku.
Počínaje skutečností, že mají odlišnou syntaxi pro každé prováděcí prostředí, konče nedostatkem standardní schopnosti přenášet proměnné z jedné fáze potrubí do druhé.
Udělám rezervaci, že hlavní příklady budou na Release Pipelines, protože tam se YAML ještě nedostal a já potřebuji funkčnost mnoha fází a mnoha artefaktů. Zdá se, že se to stalo dostupným v běžných Pipelines, což se jim prakticky vyrovná ve funkčnosti. V Pipelines YAML jsme k textové reprezentaci přidali malý grafický tooltip s parametry, které lze nastavit. Je to velmi pohodlné; nemusíte procházet dokumentaci pro každý modul. To ale popíšu v příštím článku, ale zatím zde je obrázek samotné inovace.
Skladování a použití
Začněme tím, že v systému máme výchozí proměnné. Začínají v závislosti na původu slovy Release, System atd. Úplný seznam (jak se ukázalo, ne), je k dispozici na . Veškerá schizofrenie se syntaxí je ilustrována příkladem z dokumentace níže. Stejná proměnná má tři reprezentace, podle toho, kde ji nazýváme.
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)Pokud nastavíte proměnnou u agenta, na kterém se úloha provádí, je to $(System.AccessToken). Pokud jej chcete použít ve skriptu powershell na stejném agentovi, bude to již $env:SYSTEM_ACCESSTOKEN. Pokud, nedej bože, chcete tuto proměnnou použít na nějakém vzdáleném hostiteli pomocí úlohy PowerShell na cílových počítačích, musíte to předat skriptu pomocí argumentu pomocí . S bash je to jednodušší, můžete to jednoduše předat dovnitř pomocí argumentu a syntaxe $SYSTEM_ACCESSTOKEN.
Stejné zákony neplatí pro vaše vlastní proměnné, zde již odpovídáte za syntaxi. Proměnné lze nastavit lokálně v každé úloze.
Nebo globálně do proměnné store a poté je propojte z obchodu. Velmi pohodlně.
Jako bonus, pokud jsou proměnné velmi tajné, mohou být uloženy v cloudu Azure v úložišti s názvem Azure Vault; Vault můžete propojit s projektem v knihovně.
Obecně je vše jasné s proměnnými, v kanálech je stále lze nastavit ručně pro každé spuštění, ve verzi žádná taková funkce není. V inicializačních protokolech agenta můžete znovu vidět, co přenášíte do kanálu, ale mějte na paměti, že jsou tam již v převedené podobě.
Dynamické proměnné
Zábava začíná, když chceme v jedné fázi získat nějakou hodnotu a předat ji další.
Taková funkce nám nebyla poskytnuta. Naše ruce ale nejsou pro nudu a s pomocí Googlu se našlo řešení. Díky bohu, Azure DevOps má API, které nám umožňuje dělat trochu víc, než co bylo znázorněno v rozhraní.
Budeme tedy potřebovat volání k aktualizaci globálních proměnných, které provedeme přímo z potrubí. Adresa je převzata z proměnných prostředí, stejných, o kterých není v dokumentaci ani slovo, jak bylo zmíněno dříve. Můžete si je nastavit sami, nebo je navíc pevně zakódovat, pokud obchod zavřou.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Nastavíme prázdnou hodnotu proměnné, kterou chceme přenést, nastavíme Scope - Release
Například uděláme nějaký generátor náhodných hodnot. Věnujte pozornost syntaxi deklarace proměnné v této fázi, tato funkce byla zavedena.
V dalším kroku předáme proměnnou skriptu, ano, ano, není to možné přímo, musí to být přes argument.
Scénář pod spoilerem
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))
#endregionNebo
Praštit
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_URLStručně řečeno, náš skript bere proměnnou myVar jako vstup a používá API k vložení hodnoty této proměnné do stageVar. V dalším kroku pomocí syntaxe systémové proměnné se na to můžeme podívat.
Příklad je docela jednoduchý, ale funkčnost nám kromě mých předchozích otevírá dobré příležitosti , kdy můžeme vytvořit virtuální stroj v první fázi testování, provést s ním některé další manipulace a několik paralelně. A poslední fází je jeho zničení. Nyní spouštíme autotesty produktu pokaždé na nových virtuálních strojích. Když vezmeme v úvahu, že žijí asi 10 minut, stojí to korunu.
V příštím článku budu případně mluvit o YAML pipelinech, tam je v poslední době docela dost zajímavých inovací.
Zdroj: www.habr.com