Използване на променливи в 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 да бъде свързано с проекта в библиотеката.

Общо взето, с променливите всичко е ясно; в 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