🥇Bruk av variabler i Azure DevOps-pipelines

Vi fortsetter oversikten over det fantastiske utviklingsverktøyet for Windows og mer, Azure DevOps. Denne gangen, etter å ha slitt med miljøvariabler, besluttet jeg å samle all erfaringen i én artikkel.

Fra det faktum at de har forskjellig syntaks for hver kjøringsmiljø, til mangelen på en standardmetode for å overføre variabler fra ett trinn i pipeline til et annet.

Jeg vil si at hovedeksemplene vil være på Release Pipelines, fordi YAML enda ikke er ankommet dit, og jeg trenger funksjonaliteten av flere trinn og flere artefakter. Dette ser ut til å ha blitt tilgjengelig i vanlige Pipelines, noe som nesten har jevnet ut funksjonaliteten deres. I Pipelines er YAML nå forbedret og fått en liten grafisk veiledning med parametere som kan settes. Veldig praktisk, man trenger ikke å sjekke dokumentasjonen for hver modul. Men jeg vil beskrive dette i neste artikkel, og så lenge her er et bilde av den nyeste funksjonen.

Lagring og bruk

La oss begynne med at systemet har standardvariabler. De starter, avhengig av opprinnelse, med ordene Release, System, osv. Den fullstendige listen (som det viste seg, finnes ikke), er tilgjengelig i dokumentasjonen. All galskapen med syntaksen illustreres med et eksempel fra dokumentasjonen nedenfor. Den samme variabelen har tre representasjoner avhengig av hvor vi kaller 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 setter en variabel på agenten som oppgaver kjøres på, er det $(System.AccessToken). Hvis du vil bruke den inne i et PowerShell-skript på den samme agenten, vil det allerede være $env:SYSTEM_ACCESSTOKEN. Hvis du, gud forby, vil bruke denne variabelen på en eller annen ekstern vert ved å bruke PowerShell-oppgaver på målmaskiner, må du overføre den via argumentet til skriptet ved å bruke param. Med bash er det enklere, man kan bare sende den inn ved hjelp av argumenter og syntaksen $SYSTEM_ACCESSTOKEN.

De samme reglene gjelder ikke for dine egne variabler, her er du ansvarlig for syntaksen. Variabler kan settes lokalt i hver oppgave.

Eller globalt i variabellageret, og så lenke dem fra lageret. Veldig praktisk.

I tillegg, hvis variablene er veldig hemmelige, kan de lagres i Azure Cloud i et lagringssted som heter Azure Vault. Du kan koble Vault til prosjektet i biblioteket.

Generelt er det klart hvordan variablene jobber, i pipelines kan de også settes manuelt for hver kjøring, men i release er ikke denne funksjonaliteten tilgjengelig. Du kan se hva du sender til pipelinen igjen i loggene for agendainitialisering, men husk at de allerede er der i transformert format.

Dynamiske variabler

Det mest interessante begynner når vi vil hente en viss verdi i ett trinn og sende den til neste.

Den funksjonaliteten har de ikke levert. Men våre hender er ikke til å kjede seg, og ved hjelp av Google ble det funnet en løsning. Heldigvis har Azure DevOps et API som lar oss gjøre litt mer enn det som er tegnet i grensesnittet.

Så vi trenger et kall for å oppdatere globale variabler, som vi vil gjøre direkte fra innsiden av pipelinen. Adressen hentes fra miljøvariablene, de som ikke er nevnt i dokumentasjonen, som nevnt tidligere. Du kan definere dem selv eller, for den saks skyld, hardkode dem hvis butikken stenges.

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

Vi setter en tom verdi for variabelen vi vil sende, og setter Scope - Release

Som et eksempel lager vi en tilfeldig generator av verdier. Legg merke til syntaksen for å erklære variabelen innenfor dette trinnet, slik funksjonalitet har de levert.

I det neste trinnet sender vi variabelen til skriptet, ja ja, direkte er ikke mulig, det må gå gjennom argumentet.

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 tar skriptet vårt inn variabelen myVar og bruker API-et for å sette verdien av denne variabelen til stageVar. I neste trinn kan vi se den ved å bruke syntaksen for systemvariabler.

Eksempelet er ganske enkelt, men funksjonaliteten åpner gode muligheter for oss, sammen med min forrige artikkelen, når vi kan opprette en virtuell maskin i første testfase, utføre noen manipulasjoner med den videre, og gjøre flere av dem parallelt. Som et siste steg vil vi ødelegge den. Nå kjører vi autotester av produktet hver gang på friske virtuelle maskiner. Gitt at de lever i 10 minutter, koster det bare småpenger.

I den neste artikkelen, hvis det er behov, vil jeg fortelle om YAML-pipelines, det har vært mange interessante nyheter den siste tiden.

Kilde: habr.com