Användning av variabler i Azure DevOps-pipelines

Vi fortsätter vår översikt av det fantastiska verktyget för utveckling på Windows och mer, Azure DevOps. Den här gången, efter att ha kämpat med miljövariabler, bestämde jag mig för att sammanfatta all erfarenhet i en artikel.

Från att varje körningsmiljö har olika syntax, till avsaknaden av en standardfunktion för att överföra variabler från en pipeline-steg till en annan.

Jag vill nämna att de huvudsakliga exemplen kommer att vara på Release Pipelines, eftersom YAML ännu inte har nått dit, och jag behöver funktionaliteten med flera steg och flera artefakter. Det verkar ha blivit tillgängligt i vanliga Pipelines, vilket praktiskt taget har utjämnat deras funktionalitet. I Pipelines har YAML vidareutvecklats och en liten grafisk tips med parametrar som kan ställas in har lagts till textrepresentationen. Mycket praktiskt, man behöver inte gå till dokumentationen för varje modul. Men det kommer jag att beskriva i nästa artikel, för nu här är en bild av själva nyheten.

Lagring och användning

Låt oss börja med att i systemet har vi standardvariabler. De börjar, beroende på källa, med orden Release, System, etc. Den fullständiga listan (som det visade sig, finns inte), finns i dokumentationen. Hela galenskapen med syntaxen illustreras av ett exempel från dokumentationen nedan. En och samma variabel har tre representationer, beroende på var vi anropar den.

steps:
 - bash: echo Detta skript kan använda $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "Detta är ett skript som kan använda $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Om du ställer in en variabel på agenten som utför uppgiften, är det $(System.AccessToken). Om du vill använda den i ett PowerShell-skript på samma agent, blir det redan $env:SYSTEM_ACCESSTOKEN. Om du, gud förbjude, vill använda denna variabel på en fjärrvärd, med uppgiften PowerShell på målenheter, måste du skicka den som ett argument till skriptet, med param. Med bash är det enklare, man kan bara vidarebefordra den inuti med argument och syntax $SYSTEM_ACCESSTOKEN.

De samma regler gäller inte för dina egna variabler, här bär du ansvaret för syntaxen själv. Variabler kan ställas in lokalt i varje uppgift.

Eller globalt i variabelförrådet, och sedan länka dem från förrådet. Mycket praktiskt.

Som en bonus, om variablerna är extremt hemliga, kan de lagras i Azure-molnet i en lagring som kallas Azure Vault, och Vault kan kopplas till projektet i biblioteket.

Generellt sett är det klart med variabler, i pipelines kan de också ställas in manuellt för varje körning, men den funktionen finns inte i release. Du kan se vad du skickar till pipelinen i loggarna för agentens initiering, men kom ihåg att de redan är i transformerad form där.

Dynamiska variabler

Det intressanta börjar när vi vill få ett visst värde i ett steg och överföra det till nästa.

Denna funktion har vi tyvärr inte fått. Men våra händer är inte till för att vara sysslolösa, och med hjälp av Google hittade vi en lösning. Tack och lov har Azure DevOps ett API som gör att vi kan göra lite mer än vad som tecknades i gränssnittet.

Så vi behöver ett anrop för att uppdatera globala variabler, som vi kommer att göra direkt inifrån pipelinen. Adressen tas från miljövariabler, de som inte nämns någonstans i dokumentationen, som nämnts tidigare. Du kan ställa in dem själv eller, varför inte, hårdkoda dem om de stänger av möjligheten.

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

Vi sätter ett tomt värde för variabeln som vi vill överföra och sätter Scope — Release

Som exempel skapar vi en viss slumpmässig värdeskapare. Observera syntaxen för att deklarera variabeln inom detta steg, en sådan funktion har lagts till.

I nästa steg överför vi variabeln till skriptet, ja, ja, direkt kan vi inte, det måste göras via argument.

Skriptet under spoiler

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

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

Kort sagt, vårt skript tar en variabel myVar som input och använder API:et för att lägga värdet av denna variabel i stageVar. I nästa steg, med hjälp av syntaxen för systemvariabler, kan vi se den.

Exemplet är ganska enkelt, men funktionen ger oss bra möjligheter, tillsammans med min tidigare erfarenhet. artikeln, när vi kan skapa en virtuell maskin i första teststeget, göra några manipulationer med den, dessutom parallellt med flera. Och som slutsteg förstöra den. Just nu kör vi automatiserade tester av produkten varje gång på nya virtuella maskiner. Med tanke på att de lever i ungefär 10 minuter kostar det en spottstyver.

I nästa artikel, om det behövs, kommer jag att berätta om YAML-pipelines, där det har dykt upp ganska många intressanta nyheter på sistone.

Källa: habr.com