🥇Použití proměnných v Azure DevOps pipelines

Pokračujeme v přehledu skvělého nástroje pro vývoj pro Windows a nejen to, Azure DevOps. Tentokrát, po trápení s proměnnými prostředí, jsem se rozhodl shrnout všechny zkušenosti do jednoho článku.

Začíná to tím, že pro každé prostředí spouštění mají jinou syntaxi, a končí to absencí standardní možnosti přenosu proměnných z jedné fáze pipeline do druhé.

Musím zmínit, že hlavní příklady budou na Release Pipelines, protože YAML sem ještě nedorazil a já potřebuju funkcionalitu mnoha etap a artefaktů. To se zdá, že se stalo dostupným v běžných Pipelines, což je prakticky vyrovnalo v funkcionalitě. V Pipelines do YAML přidali menší grafickou nápovědu s parametry, které lze nastavit. Opravdu pohodlné, není třeba procházet dokumentaci pro každý modul. Ale o tom budu psát v dalším článku, zatím tady je obrázek samotného nového prvku.

Uložení a používání

Začneme tím, že v systému máme výchozí proměnné. Ty začínají, v závislosti na původu, slovy Release, System, atd. Úplný seznam (jak se ukázalo, žádný), je k dispozici na dokumentaci. Celou schizofrenii se syntaxí ilustruje příklad z dokumentace níže. U jedné a téže proměnné existují tři zobrazení, v závislosti na tom, kde ji volá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 na agentovi, na kterém úkol běží, je to $(System.AccessToken). Pokud ji chcete použít uvnitř powershell skriptu 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í úkolu PowerShell na cílových strojích, musíte ji předat jako argument skriptu pomocí param. S bash je to jednodušší, můžete ji jednoduše předat dovnitř s použitím argumentu a syntaxe $SYSTEM_ACCESSTOKEN.

Stejná pravidla se nevztahují na vaše vlastní proměnné, zde už nesete odpovědnost za syntaxi. Proměnné lze nastavit lokálně v každém úkolu.

Nebo globálně ve skladu proměnných a pak je propojit ze skladu. Opravdu pohodlné.

K tomu, pokud jsou proměnné velmi tajné, lze je uchovávat v cloudu Azure v úložišti nazvaném Azure Vault. Vault lze propojit s projektem v knihovně.

Obecně, co se proměnných týče, v pipelines je ještě možné je zadat ručně při každém spuštění, ale v releasu tato funkčnost chybí. Můžete se podívat na to, co do pipeline předáváte, ještě jednou v logech inicializace agenta, ale mějte na paměti, že tam už jsou v převedené podobě.

Dynamické proměnné

To nejzajímavější začíná, když chceme získat nějakou hodnotu v jednom kroku a předat ji do dalšího.

Taková funkčnost nebyla implementována. Ale naše ruce nejsou na nic, a pomocí Googlu bylo nalezeno řešení. Naštěstí má Azure DevOps API, které nám umožňuje udělat trochu více, než co je zobrazeno v rozhraní.

Takže budeme potřebovat volání pro aktualizaci globálních proměnných, které provedeme přímo z pipeline. Adresa je získána z proměnných prostředí, o nichž se v dokumentaci vůbec nezmiňuje, jak bylo zmíněno dříve. Můžete je zadat sami nebo, co si budeme povídat, hardcodovat, pokud by to byla poslední možnost.

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

Zadáváme prázdnou hodnotu proměnné, kterou chceme předat, nastavujeme Scope — Release

Pro příklad vytvořme nějaký náhodný generátor hodnot. Všimněte si syntaxe pro deklaraci proměnné uvnitř této fáze, taková funkčnost byla implementována.

V další fázi předáváme proměnnou skriptu, ano, přímo to nelze, musí to být skrze argument.

Skript 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))
#endregion

Nebo

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

Stručně řečeno, náš skript bere proměnnou myVar jako vstup a pomocí API ukládá hodnotu této proměnné do stageVar. V následující fázi, pomocí syntaxe systémových proměnných, můžeme její hodnotu vidět.

Příklad je celkem jednoduchý, ale funkčnost nám otevírá dobré možnosti, v kombinaci s mými předchozími zkušenostmi. článkem, když můžeme vytvořit virtuální stroj v první fázi testování, provést s ním nějaké operace a dokonce je dělat paralelně. A na konci ji zničit. V současné době se na čerstvých virtuálních strojích každýkrát spouštějí automatizované testy produktu. Vzhledem k tomu, že žijí přibližně 10 minut, stojí to pár korun.

V dalším článku, pokud to bude potřeba, popíšu YAML pipeline, tam nedávno vzniklo velké množství zajímavých novinek.

Zdroj: habr.com

Používání proměnných v pipelinech Azure DevOps

Uložení a používání

Dynamické proměnné