Använda variabler i Azure DevOps-pipelines

Vi fortsätter vår granskning av ett underbart verktyg för utveckling för Windows och mer, Azure DevOps. Den här gången, efter att ha lidit mycket av miljövariabler, bestämde jag mig för att lägga all erfarenhet i en artikel.

Utgående från det faktum att de har olika syntax för varje exekveringsmiljö, slutar med avsaknaden av en standardförmåga att överföra variabler från ett steg i pipelinen till ett annat.

Jag reserverar mig för att de viktigaste exemplen kommer att finnas på Release Pipelines, eftersom YAML inte har kommit dit ännu, och jag behöver funktionaliteten för många stadier och många artefakter. Detta verkar ha blivit tillgängligt i vanliga pipelines, vilket praktiskt taget motsvarar dem i funktionalitet. I Pipelines YAML lade vi till ett litet grafiskt verktygstips till textrepresentationen med parametrar som kan ställas in. Det är väldigt bekvämt; du behöver inte gå igenom dokumentationen för varje modul. Men jag kommer att beskriva detta i nästa artikel, men för nu kommer här en bild på själva innovationen.

Förvaring och användning

Låt oss börja med att vi har standardvariabler i systemet. De börjar, beroende på ursprung, med orden Release, System, etc. Den fullständiga listan (som det visar sig inte), finns tillgänglig på dokumentation. All schizofreni med syntax illustreras med ett exempel från dokumentationen nedan. Samma variabel har tre representationer, beroende på var vi kallar den.

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)

Om du ställer in en variabel på agenten som uppgiften exekveras på är den $(System.AccessToken). Om du vill använda det i ett powershell-skript på samma agent, kommer det redan att vara $env:SYSTEM_ACCESSTOKEN. Om du, gud förbjude, vill använda den här variabeln på någon fjärrvärd som använder uppgiften PowerShell på målmaskiner, måste du skicka detta genom ett argument till skriptet med param. Med bash är det enklare, du kan helt enkelt skicka in det med argumentet och syntaxen $SYSTEM_ACCESSTOKEN.

Samma lagar gäller inte för dina egna variabler, här är du redan ansvarig för syntaxen. Variabler kan ställas in lokalt i varje uppgift.

Eller globalt till variabelbutiken och länka dem sedan från butiken. Mycket bekvämt.

Som en bonus, om variablerna är mycket hemliga, kan de lagras i Azure-molnet i en lagring som heter Azure Vault; du kan länka Vault till projektet i biblioteket.

I allmänhet är allt tydligt med variabler, i pipelines kan de fortfarande ställas in manuellt för varje lansering, i release finns ingen sådan funktionalitet. Du kan se vad du överför till pipelinen igen i agentinitieringsloggarna, men tänk på att de redan finns där i konverterad form.

Dynamiska variabler

Det roliga börjar när vi vill ta emot lite värde i ett steg och skicka det till nästa.

Vi försågs inte med sådan funktionalitet. Men våra händer är inte för tristess och med hjälp av Google hittades en lösning. Tack och lov har Azure DevOps ett API som gör att vi kan göra lite mer än vad som avbildades i gränssnittet.

Så vi kommer att behöva ett samtal för att uppdatera globala variabler, vilket vi kommer att göra direkt från pipelinen. Adressen är hämtad från miljövariabler, samma som det inte står ett ord om i dokumentationen, som tidigare nämnts. Du kan ställa in dem själv eller, vad mer, hårdkoda dem om de stänger butiken.

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

Vi ställer in det tomma värdet på variabeln som vi vill överföra, ställer in Scope - Release

Till exempel gör vi någon slumpmässig värdegenerator. Var uppmärksam på syntaxen för att deklarera en variabel i detta steg; denna funktion introducerades.

I nästa steg skickar vi variabeln till skriptet, ja, ja, det är inte möjligt direkt, det måste vara genom ett argument.

Skript under spoiler

Power

#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

Eller

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

I ett nötskal tar vårt skript variabeln myVar som indata och använder API:et för att sätta värdet på denna variabel i stageVar. I nästa steg, med hjälp av systemvariabelsyntax, kan vi titta på det.

Exemplet är ganska enkelt, men funktionaliteten öppnar upp för goda möjligheter för oss, utöver mina tidigare artiklar, när vi kan skapa en virtuell maskin i det första teststeget, utför några ytterligare manipulationer med den, och flera parallellt. Och det sista steget är att förstöra det. Nu kör vi autotester av produkten varje gång på färska virtuella maskiner. Med tanke på att de lever i ca 10 minuter så kostar det en slant.

I nästa artikel kommer jag, om det behövs, att prata om YAML-pipelines; det har funnits en hel del intressanta innovationer där på sistone.

Källa: will.com