ProHoster > блог > адміністраванне > Выкарыстанне зменных у пайплайнах Azure DevOps

Выкарыстанне зменных у пайплайнах Azure DevOps

Працягваем агляд выдатнай тулы для распрацоўкі пад Windows і не толькі, Azure DevOps. На гэты раз, намучыўшыся са зменнымі асяроддзі, я вырашыў вынесці ўвесь досвед у адзін артыкул.

Пачынальна ад таго, што для кожнага асяроддзя выканання ў іх розны сінтаксіс, сканчаючы адсутнасцю стандартнай магчымасці пераносу зменных з адной стадыі пайплайна ў іншую.

Абмоўлюся, што асноўныя прыклады будуць на Release Pipelines, таму, што YAML туды яшчэ не даехаў, а мне патрэбна функцыянальнасць мноства этапаў і мноства артэфактаў. Гэта, накшталт, стала даступна ў звычайных Pipelines, што практычна ўзраўнавала іх па функцыянальнасці. У Pipelines YAML дапілавалі і дадалі да тэкставага прадстаўлення, невялікую графічную падказку з параметрамі, якія можна задаць. Вельмі зручна, не трэба лезці ў дакументацыю па кожным модулі. Але гэта буду апісваць у наступным артыкуле, а пакуль вось карцінка самага новаўвядзення.

Выкарыстанне зменных у пайплайнах Azure DevOps

Захоўванне і выкарыстанне

Пачнём з таго, што ў сістэме ў нас ёсць зменныя па змаўчанні. Яны пачынаюцца, у залежнасці ад паходжання, са слоў Release, System, etc. Поўны спіс (як аказалася, не), даступны ў дакументацыі. Усю шызафрэнію з сінтаксісам ілюструе прыклад з дакументацыі ніжэй. У адной і той жа зменнай ёсць тры ўяўленні, у залежнасці ад таго, дзе мы яе выклікаем.

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, вам трэба перадаць гэта праз аргумент да скрыпту, выкарыстаючы парам. З bash прасцей, можна проста пракідаць унутр выкарыстоўваючы аргумент і сінтаксіс $SYSTEM_ACCESSTOKEN.

Тыя ж законы не распаўсюджваюцца на вашыя ўласныя зменныя, тут ужо вы несяце адказнасць за сінтаксіс. Задаць зменныя можна лакальна ў кожнай задачы.

Выкарыстанне зменных у пайплайнах Azure DevOps

Або глабальна ў сховішча зменных, а потым лінкаваць іх са сховішча. Вельмі зручна.

Выкарыстанне зменных у пайплайнах Azure DevOps

Бонусам да гэтага, калі зменныя надта сакрэтныя, іх можна захоўваць у воблаку Azure у сховішча пад назовам Azure Vault, залінкаваць Vault да праекту можна ў Library.

Выкарыстанне зменных у пайплайнах Azure DevOps

У цэлым са зменнымі ўсё зразумела, у pipelines іх яшчэ можна задаваць у ручную на кожны запуск, у release такой функцыянальнасці няма. Паглядзець што вы перадаеце ў пайплайн можна яшчэ раз у логах ініцыялізацыі агента, але ўлічыце, яны тамака ўжо ў пераўтвораным выглядзе.

Выкарыстанне зменных у пайплайнах Azure DevOps

Дынамічныя зменныя

Самае цікавае пачынаецца, калі мы хочам атрымаць некаторае значэнне ў адным этапе і перадаць яго ў наступны.

Выкарыстанне зменных у пайплайнах Azure DevOps

Такой функцыянальнасці нам не завезлі. Але нашы рукі не для нуды і пры дапамозе гугла было знойдзена рашэнне. Дзякуй богу, у 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

Выкарыстанне зменных у пайплайнах Azure DevOps

Для прыкладу які робіцца некаторы рандомный генератар значэнняў. Звярніце ўвагу на сінтаксіс аб'явы зменнай усярэдзіне гэтага этапу, такі функцыянал завезлі.

Выкарыстанне зменных у пайплайнах Azure DevOps

У наступным этапе мы перадаем зменную скрыпту, ды так, наўпрост нельга, трэба праз аргумент.

Выкарыстанне зменных у пайплайнах Azure DevOps

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

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

Або

Біць

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. У наступным этапе, выкарыстоўваючы сінтаксіс сістэмных зменных, мы можам яе паглядзець.

Выкарыстанне зменных у пайплайнах Azure DevOps

Прыклад даволі просты, але функцыянал адкрывае нам добрыя магчымасці, у суме з маёй мінулай артыкулам, калі мы можам стварыць віртуальную машыну на першым этапе тэсціравання, прарабіць з ёй нейкія маніпуляцыі далей, прычым паралельна некалькі. І фінальным этапам яе знішчыць. Цяпер у нас ганяюцца аўтатэсты прадукта кожны раз на свежых віртуалках. Улічваючы, што жывуць яны хвілін 10, каштуе гэта капейкі.

У наступным артыкуле, калі будзе неабходнасць, раскажу пра YAML пайплайны, там даволі шмат цікавых новаўвядзенняў апошнім часам.

Крыніца: habr.com

Дадаць каментар