Gebruik veranderlikes in Azure DevOps-pyplyne

Ons gaan voort met ons hersiening van 'n wonderlike hulpmiddel vir ontwikkeling vir Windows en meer, Azure DevOps. Hierdie keer, nadat ek baie gely het met omgewingsveranderlikes, het ek besluit om al die ervaring in een artikel te plaas.

Begin van die feit dat hulle verskillende sintaksis vir elke uitvoeringsomgewing het, en eindig met die gebrek aan 'n standaardvermoë om veranderlikes van een stadium van die pyplyn na 'n ander oor te dra.

Ek sal 'n bespreking maak dat die hoofvoorbeelde op Release Pipelines sal wees, want YAML het nog nie daar gekom nie, en ek benodig die funksionaliteit van baie stadiums en baie artefakte. Dit blyk dat dit beskikbaar geword het in gewone Pipelines, wat feitlik gelyk is aan hulle in funksionaliteit. In Pipelines YAML het ons 'n klein grafiese nutswenk by die teksvoorstelling gevoeg met parameters wat gestel kan word. Dit is baie gerieflik; jy hoef nie deur die dokumentasie vir elke module te gaan nie. Maar ek sal dit in die volgende artikel beskryf, maar vir eers is hier 'n prentjie van die innovasie self.

Berging en gebruik

Kom ons begin met die feit dat ons verstekveranderlikes in die stelsel het. Hulle begin, afhangende van hul oorsprong, met die woorde Release, System, ens. Die volledige lys (soos dit blyk nie), is beskikbaar by dokumentasie. Alle skisofrenie met sintaksis word geïllustreer deur 'n voorbeeld uit die dokumentasie hieronder. Dieselfde veranderlike het drie voorstellings, afhangend van waar ons dit noem.

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)

As jy 'n veranderlike op die agent stel waarop die taak uitgevoer word, is dit $(System.AccessToken). As jy dit binne 'n powershell script op dieselfde agent wil gebruik, sal dit reeds $env:SYSTEM_ACCESSTOKEN wees. As jy, God verhoede, hierdie veranderlike op een of ander afgeleë gasheer wil gebruik deur die PowerShell op teikenmasjiene-taak te gebruik, moet jy dit deur 'n argument na die skrif stuur deur my geld. Met bash is dit eenvoudiger, jy kan dit eenvoudig binne deur die argument en sintaksis $SYSTEM_ACCESSTOKEN gebruik.

Dieselfde wette geld nie vir jou eie veranderlikes nie; hier is jy reeds verantwoordelik vir die sintaksis. Veranderlikes kan plaaslik in elke taak gestel word.

Of globaal na die veranderlike winkel, en koppel hulle dan vanaf die winkel. Baie gemaklik.

As 'n bonus, as die veranderlikes baie geheim is, kan hulle in die Azure-wolk gestoor word in 'n berging genaamd Azure Vault; jy kan Vault aan die projek in die Biblioteek koppel.

Oor die algemeen is alles duidelik met veranderlikes; in pyplyne kan hulle steeds handmatig vir elke bekendstelling ingestel word; in vrystelling is daar nie so 'n funksionaliteit nie. Jy kan weer sien wat jy na die pyplyn oordra in die agent se inisialisering logs, maar hou in gedagte dat hulle reeds daar is in omgeskakelde vorm.

Dinamiese veranderlikes

Die pret begin wanneer ons 'n bietjie waarde in een stadium wil ontvang en dit na die volgende wil oordra.

Ons is nie van sulke funksionaliteit voorsien nie. Maar ons hande is nie vir verveling nie en met die hulp van Google is 'n oplossing gevind. Dank God, Azure DevOps het 'n API wat ons toelaat om 'n bietjie meer te doen as wat in die koppelvlak uitgebeeld is.

Dus, ons sal 'n oproep nodig hê om globale veranderlikes op te dateer, wat ons direk vanuit die pyplyn sal doen. Die adres is geneem uit omgewingsveranderlikes, dieselfde waaroor daar nie 'n woord in die dokumentasie is nie, soos vroeër genoem. Jy kan dit self stel of, wat meer is, hulle hardkodeer as hulle die winkel sluit.

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

Ons stel die leë waarde van die veranderlike wat ons wil oordra, stel Scope - Release

Ons maak byvoorbeeld een of ander ewekansige waardegenerator. Gee aandag aan die sintaksis om 'n veranderlike binne hierdie stadium te verklaar; hierdie funksionaliteit is bekendgestel.

In die volgende stap gee ons die veranderlike deur na die skrif, ja, ja, dit is nie direk moontlik nie, dit moet deur 'n argument wees.

Skripsie onder bederf

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

Of

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

In 'n neutedop, ons skrif neem die veranderlike myVar as invoer en gebruik die API om die waarde van hierdie veranderlike in stageVar te plaas. In die volgende stap, met behulp van stelselveranderlike sintaksis, kan ons daarna kyk.

Die voorbeeld is redelik eenvoudig, maar die funksionaliteit bied goeie geleenthede vir ons, benewens my vorige artikel, wanneer ons 'n virtuele masjien in die eerste stadium van toetsing kan skep, voer 'n paar verdere manipulasies daarmee uit, en verskeie parallel. En die laaste stadium is om dit te vernietig. Nou voer ons outotoetse van die produk elke keer op vars virtuele masjiene uit. As in ag geneem word dat hulle sowat 10 minute leef, kos dit 'n sent.

In die volgende artikel sal ek, indien nodig, oor YAML-pypleidings praat; daar was die afgelope tyd nogal baie interessante innovasies daar.

Bron: will.com