Използване на променливи в пайплайни Azure DevOps

Продължаваме прегледа на страхотния инструмент за разработка за Windows и не само, Azure DevOps. Този път, след като се борих с променливите на средата, реших да обобщя целия си опит в една статия.

Започвайки от това, че за всяка среда на изпълнение имат различен синтаксис, и завършвайки с липсата на стандартна възможност за пренасяне на променливи от една фаза на конвейера в друга.

Ще уточня, че основните примери ще бъдат на Release Pipelines, защото YAML все още не е прилаган там, а на мен ми трябва функционалност с множество етапи и множество артефакти. Това, изглежда, стана достъпно в обикновените Pipelines, което практически ги изравнява по функционалност. В Pipelines YAML допълниха и добавиха към текстовото представяне малък графичен индикатор с параметрите, които могат да бъдат зададени. Много удобно, не е необходимо да се ровите в документацията за всеки модул. Но това ще опиша в следващата статия, а за сега ето изображение на самото нововъведение.

Съхранение и използване

Да започнем с това, че в системата имаме променливи по подразбиране. Те започват, в зависимост от произхода, със словата Release, System и др. Пълен списък (както се оказа, няма такъв) е наличен в документацията. Цялата шизофрения със синтаксиса илюстрира пример от документацията по-долу. Една и съща променлива има три представяния, в зависимост от това къде я извикваме.

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)

Ако зададете променлива на агента, на който се изпълнява задачата, това е $(System.AccessToken). Ако искате да я използвате в powershell скрипт на същия агент, ще бъде $env:SYSTEM_ACCESSTOKEN. Ако, не дай си боже, искате да използвате тази променлива на някакъв отдалечен хост, използвайки задачата PowerShell on target machines, трябва да я предадете чрез аргумент на скрипта, използвайки param. С bash е по-лесно, просто можете да я предавате вътре, използвайки аргумент и синтаксиса $SYSTEM_ACCESSTOKEN.

Тези същите правила не важат за вашите собствени променливи, тук вече вие носите отговорност за синтаксиса. Променливите могат да бъдат зададени локално за всяка задача.

Или глобално в хранилището на променливи, а след това да ги линквате от хранилището. Много удобно.

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

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

Динамични променливи

Най-интересното започва, когато искаме да получим определена стойност на един етап и да я предадем на следващия.

Такава функционалност не ни е предоставена. Но ръцете ни не са безделници и с помощта на 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

Или

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. На следващия етап, използвайки синтаксиса на системните променливи, можем да я видим.

Примерът е доста прост, но функционалността ни отваря добри възможности, в комбинация с моето предишно статия, когато можем да създадем виртуална машина на първия етап от тестването, да извършим с нея някои манипулации, и то паралелно с няколко. А на финалния етап да я разрушим. В момента провеждаме автоматични тестове на продукта всеки път на нови виртуални машини. С оглед на това, че живеят около 10 минути, това струва малко.

В следващата статия, ако е необходимо, ще разкажа за YAML пайплайните, там има доста интересни нововъведения напоследък.

Източник: habr.com