Vi fortsætter vores gennemgang af et vidunderligt værktøj til udvikling til Windows og mere, Azure DevOps. Denne gang, efter at have lidt meget med miljøvariabler, besluttede jeg at samle alle erfaringerne i én artikel.
Startende fra det faktum, at de har forskellig syntaks for hvert eksekveringsmiljø, og slutter med manglen på en standardevne til at overføre variabler fra et trin i pipelinen til et andet.
Jeg tager forbehold for, at hovedeksemplerne vil være på Release Pipelines, fordi YAML ikke er nået dertil endnu, og jeg har brug for funktionaliteten af mange stadier og mange artefakter. Det ser ud til, at dette er blevet tilgængeligt i almindelige Pipelines, hvilket praktisk talt svarer til dem i funktionalitet. I Pipelines YAML har vi tilføjet et lille grafisk værktøjstip til tekstgengivelsen med parametre, der kan indstilles. Det er meget praktisk; du behøver ikke at gennemgå dokumentationen for hvert modul. Men det vil jeg beskrive i den næste artikel, men indtil videre er her et billede af selve innovationen.
Opbevaring og brug
Lad os starte med, at vi har standardvariabler i systemet. De begynder, afhængigt af deres oprindelse, med ordene Release, System osv. Den fulde liste (som det viser sig ikke), er tilgængelig på . Al skizofreni med syntaks er illustreret med et eksempel fra dokumentationen nedenfor. Den samme variabel har tre repræsentationer, alt efter 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 indstiller en variabel på den agent, som opgaven udføres på, er den $(System.AccessToken). Hvis du vil bruge det inde i et powershell-script på den samme agent, vil det allerede være $env:SYSTEM_ACCESSTOKEN. Hvis du, gud forbyde, ønsker at bruge denne variabel på en fjernvært ved hjælp af PowerShell på målmaskiner-opgaven, skal du sende dette gennem et argument til scriptet vha. . Med bash er det enklere, du kan simpelthen sende det ind ved hjælp af argumentet og syntaksen $SYSTEM_ACCESSTOKEN.
De samme love gælder ikke for dine egne variabler, her er du allerede ansvarlig for syntaksen. Variabler kan indstilles lokalt i hver opgave.
Eller globalt til den variable butik, og link dem derefter fra butikken. Meget behageligt.
Som en bonus, hvis variablerne er meget hemmelige, kan de gemmes i Azure-skyen i et lager kaldet Azure Vault; du kan linke Vault til projektet i biblioteket.
Generelt er alt klart med variabler; i pipelines kan de stadig indstilles manuelt for hver lancering; i release er der ingen sådan funktionalitet. Du kan se, hvad du overfører til pipelinen igen i agentinitialiseringsloggene, men husk, at de allerede er der i konverteret form.
Dynamiske variabler
Det sjove begynder, når vi ønsker at modtage noget værdi i et trin og videregive det til det næste.
Vi var ikke udstyret med en sådan funktionalitet. Men vores hænder er ikke til kedsomhed, og med hjælp fra Google blev der fundet en løsning. Gudskelov har Azure DevOps en API, der giver os mulighed for at gøre lidt mere end det, der blev afbildet i grænsefladen.
Så vi har brug for en opfordring til at opdatere globale variabler, hvilket vi vil gøre direkte fra pipelinen. Adressen er taget fra miljøvariabler, de samme som der ikke står et ord om i dokumentationen, som tidligere nævnt. Du kan selv indstille dem eller, hvad mere er, hardkode dem, hvis de lukker butikken.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Vi indstiller den tomme værdi af den variabel, som vi vil overføre, indstiller Scope - Release
For eksempel laver vi en tilfældig værdigenerator. Vær opmærksom på syntaksen for at erklære en variabel i dette trin; denne funktionalitet blev introduceret.
I næste trin sender vi variablen til scriptet, ja, ja, det er ikke muligt direkte, det skal være gennem et argument.
Script 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))
#endregioneller
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_URLI en nøddeskal tager vores script variablen myVar som input og bruger API'et til at sætte værdien af denne variabel i stageVar. I det næste trin, ved hjælp af systemvariabel syntaks, kan vi se på det.
Eksemplet er ret simpelt, men funktionaliteten åbner gode muligheder for os, udover mine tidligere , når vi kan oprette en virtuel maskine i den første fase af testen, udføre nogle yderligere manipulationer med den, og flere sideløbende. Og den sidste fase er at ødelægge den. Nu kører vi autotest af produktet hver gang på friske virtuelle maskiner. Taget i betragtning, at de lever i omkring 10 minutter, koster det en krone.
I den næste artikel vil jeg om nødvendigt tale om YAML-rørledninger; der har været en del interessante innovationer der på det seneste.
Kilde: www.habr.com