🥇Brug af variabler i Azure DevOps pipelines

Vi fortsætter gennemgangen af det fantastiske værktøj til udvikling på Windows og mere, Azure DevOps. Denne gang, efter at have kæmpet med miljøvariabler, besluttede jeg at samle al min erfaring i en artikel.

Fra det faktum, at de har forskellige syntakser for hvert kørekort, til den manglende standardmulighed for at overføre variabler fra en fase af pipeline til en anden.

Jeg vil dog nævne, at de primære eksempler vil være på Release Pipelines, fordi YAML endnu ikke er blevet implementeret der, og jeg har brug for funktionaliteten med flere trin og mange artefakter. Det ser ud til, at dette er blevet tilgængeligt i almindelige Pipelines, hvilket praktisk taget har niveaureret deres funktionalitet. I Pipelines er YAML blevet forbedret og tilføjet til den tekstlige repræsentation, med en lille grafisk vejledning med de parametre, der kan angives. Meget praktisk, du behøver ikke at kigge i dokumentationen for hver enkelt modul. Men det vil jeg beskrive i næste artikel, for nu er her billedet af den nye funktion.

Opbevaring og brug

Lad os starte med, at der er standardvariabler i systemet. De starter, afhængig af deres oprindelse, med ordene Release, System osv. Den fulde liste (som det viste sig, findes ikke) er tilgængelig i dokumentationen. Hele skizofrénien omkring syntaksen illustreres med eksemplet fra dokumentationen nedenfor. Den samme variabel har tre repræsentationer, afhængig af hvor vi kalder 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)

Hvis du angiver en variabel på agenten, der udfører opgaven, er det $(System.AccessToken). Hvis du vil bruge den inde i et PowerShell-script på den samme agent, bliver det $env:SYSTEM_ACCESSTOKEN. Hvis du, Gud forbyde, vil bruge denne variabel på en ekstern vært ved at bruge PowerShell-opgaven på målet, skal du videregive den som et argument til scriptet ved at bruge param. Med bash er det simplere, du kan blot videregive den ind ved at bruge argumentet og syntaksen $SYSTEM_ACCESSTOKEN.

De samme regler gælder ikke for dine egne variabler; her er det dig, der bærer ansvaret for syntaksen. Variabler kan angives lokalt i hver opgave.

Eller globalt i et variabellager, og derefter linke dem fra lageret. Meget praktisk.

Som bonus kan meget hemmelige variabler opbevares i Azure's cloud i et lager kaldet Azure Vault, som kan linkes til projektet i biblioteket.

Generelt er variablerne forstået, i pipelines kan de stadig angives manuelt ved hver opstart, men denne funktionalitet findes ikke ved release. Du kan se, hvad du sender til pipelinen igen i agensens initialiseringslogfiler, men husk, at de er der i en omdannet form.

Dynamiske variabler

Det mest interessante begynder, når vi vil hente en værdi i et trin og overføre den til næste.

Denne funktionalitet er desværre ikke tilgængelig. Men lad os ikke kede os, og med hjælp fra Google blev der fundet en løsning. Heldigvis har Azure DevOps et API, der giver os mulighed for at gøre lidt mere, end hvad der er tegnet i grænsefladen.

Så vi har brug for et kald til opdatering af globale variabler, som vi vil udføre direkte inde i pipelinen. Adressen hentes fra miljøvariabler, de samme, der ikke er nævnt i dokumentationen, som tidligere nævnt. Du kan selv definere dem, eller faktisk hårdkode dem, hvis mulighederne lukkes.

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

Vi sætter en tom værdi til variablen, som vi ønsker at overføre, og sætter Scope til Release.

For eksempel laver vi en tilfældig generator af værdier. Vær opmærksom på syntaksen til erklæring af variablen inden for dette trin, sådan funktionalitet er blevet tilføjet.

I det næste trin overfører vi variablen til scriptet, ja, direkte kan det ikke lade sig gøre, det skal gøres gennem et argument.

Scriptet 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, vores script tager en indgangsvariabel myVar og bruger API'et til at placere værdien af denne variabel i stageVar. I det næste trin, ved hjælp af syntaksen for systemvariabler, kan vi se den.

Eksemplet er ret simpelt, men funktionaliteten åbner gode muligheder i kombination med mit tidligere. en artikel, når vi kan oprette en virtuel maskine i det første testtrin, udføre nogle manipulationer med den videre, og faktisk køre flere parallelt. Og den sidste fase er at destruere den. Lige nu kører vi automatiserede tests af produktet hver gang på friske virtuelle maskiner. Givet at de lever i cirka 10 minutter, koster det næsten ingenting.

I den næste artikel, hvis der er behov for det, vil jeg fortælle om YAML pipelines; der er kommet en del interessante innovationer for nylig.

Kilde: habr.com