🥇Uporaba spremenljivk v Azure DevOps pipelines

Nadal bomo obravnavali čudovito orodje za razvoj na Windows in ne samo, Azure DevOps. Tokrat, po mučnih izkušnjah s spremenljivkami okolja, sem se odločil, da vse znanje združim v en članek.

Začnemo s tem, da ima vsako izvajalno okolje svojo sintakso, končamo pa z odsotnostjo standardne možnosti prenosa spremenljivk iz enega koraka v drugega v pipeline-u.

Dovolite, da se opredelim, da bodo glavni primeri na Release Pipelines, ker YAML še ni prišel tja, jaz pa potrebujem funkcionalnost več faz in več artefaktov. To se je, zdi se, postalo dostopno v običajnih Pipelines, kar praktično izenačuje njihovo funkcionalnost. V Pipelines je YAML prenovljen in dodan tekstovni predstavitvi ter majhnemu grafičnemu nasvetu s parametri, ki jih je mogoče nastaviti. Zelo priročno, ni treba brskati po dokumentaciji za vsak modul. Ampak to bom opisal v naslednjem članku, za zdaj pa tukaj je slika same novosti.

Shranjevanje in uporaba

Začnimo s tem, da v sistemu obstajajo privzete spremenljivke. Te se začnejo, odvisno od izvora, z besedami Release, System itd. Popoln seznam (kot se je izkazalo, ne obstaja) je na voljo na dokumenti. Vso šizofrenijo s sintakso ponazarja primer iz dokumentacije spodaj. Ena in ista spremenljivka ima tri predstavitve, odvisno od tega, kje jo kličemo.

steps:
 - bash: echo Ta skripta bi lahko uporabila $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "To je skripta, ki bi lahko uporabila $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Če nastavite spremenljivko na agenta, na katerem se izvaja naloga, je to $(System.AccessToken). Če jo želite uporabiti znotraj skripte powershell na istem agentu, bo to že $env:SYSTEM_ACCESSTOKEN. Če, nehajte bog, želite to spremenljivko uporabiti na kakšnem oddaljenem gostitelju, pri čemer uporabljate nalogo PowerShell on target machines, jo morate prenesti prek argumenta skriptu, s pomočjo param. S bash je enostavneje, lahko jo preprosto podate z uporabo argumenta in sintakse $SYSTEM_ACCESSTOKEN.

Te iste zakonitosti se ne uporabljajo za vaše lastne spremenljivke, tukaj ste že vi odgovorni za sintakso. Spremenljivke lahko nastavite lokalno v vsaki nalogi.

Ali globalno v skladišču spremenljivk, nato pa jih povežete iz skladišča. Zelo priročno.

Кроме того, если переменные очень секретные, их можно хранить в облаке Azure в хранилище под названием Azure Vault, связать Vault с проектом можно в Library.

В целом с переменными все понятно, в pipelines их еще можно задавать вручную на каждый запуск, в release такой функциональности нет. Посмотреть, что вы передаете в пайплайн, можно еще раз в логах инициализации агента, но учтите, они там уже в преобразованном виде.

Dinamične spremenljivke

Самое интересное начинается, когда мы хотим получить некоторое значение на одном этапе и передать его на следующий.

Такой функциональности нам не предоставили. Но наши руки не для скуки, и с помощью Google было найдено решение. Слава богу, у Azure DevOps есть API, который позволяет сделать чуть больше, чем нарисовано в интерфейсе.

Итак, нам понадобится вызов для обновления глобальных переменных, который мы будем делать прямо изнутри пайплайна. Адрес берется из переменных окружения, о которых в документации не сказано ни слова, как упоминалось ранее. Вы можете их задать самостоятельно или, что уж там, захардкодить, если возможность будет закрыта.

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

Задаем пустое значение переменной, которую мы хотим передать, ставим Scope — Release.

Для примера делаем некоторый рандомный генератор значений. Обратите внимание на синтаксис объявления переменной внутри этого этапа, такой функционал добавили.

На следующем этапе мы передаем переменную скрипту, да, да, напрямую нельзя, нужно через аргумент.

Скрипт под спойлером

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

Ili

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

В двух словах, наш скрипт принимает переменную myVar и, используя API, помещает значение этой переменной в stageVar. На следующем этапе, используя синтаксис системных переменных, мы можем её посмотреть.

Пример довольно простой, но функционал открывает нам хорошие возможности в совокупности с моей предыдущей članek, ko lahko ustvarimo virtualni stroj v prvem koraku testiranja, izvedemo z njim nekaj manipulacij naprej, in to hkrati za več. In končni korak je njegovo uničenje. Trenutno se pri nas avtomatski testi produkta izvajajo vsakič na svežih virtualkah. Glede na to, da živijo 10 minut, stane to malenkost.

V naslednjem članku, če bo potrebno, bom govoril o YAML pipelines, kjer je v zadnjem času precej zanimivih novosti.

Izvor: habr.com

Uporaba spremenljivk v Azure DevOps delovnih tokovih

Shranjevanje in uporaba

Dinamične spremenljivke