Muutuja kasutamine Azure DevOps'i torudes

Jätkame imetabase Windowsi arendustööriista Azure DevOps ülevaate tegemist. Seekord, pärast keskkonnamuutujatega vaeva nägemist, otsustasin kogu oma kogemuse ühe artikli peale koondada.

Alates sellest, et iga töötluskeskkonna jaoks on neil erinev süntaks, kuni standardse võimaluse puudumiseni muutujaid ühest etappest teise edastada.

Mõneni, peamised näited on Release Pipelines, kuna YAML ei ole sinna veel jõudnud ja mulle on vajalik mitme etapi ning mitme artefakti funktsionaalsus. Tundub, et see on tavalistes Pipelines nüüdseks kergesti saadaval ja peaaegu tasakaalustanud nende funktsionaalsuse. Pipelines'i YAML on täiustatud ja sellele tekstipõhisele esitlusele on lisatud väike graafiline abifunktsioon parameetrite määramiseks. Väga mugav, ei pea iga mooduli dokumentatsiooni otsima. Kuid seda kirjeldan järgmises artiklis, aga siinkohal on pilt uuest funktsioonist.

Salvestamine ja kasutamine

Alustame sellest, et süsteemis on meil vaikimisi muutujaid. Need algavad, olenevalt päritolust, sõnadega Release, System jne. Täielik loetelu (nagu selgub, ei ole) on saadaval dokumentatsioon. Kogu süntaksihullus on illustreeritud allolevas dokumentatsiooni näites. Ühel ja samal muutujal on kolm esitamist, sõltuvalt sellest, kus me seda kutsub.

steps:
 - bash: echo See skript võiks kasutada $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "See on skript, mis võiks kasutada $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Kui määrate muutuja ülesandes, kus ülesanne käib, on see $(System.AccessToken). Kui soovite kasutada seda powershell skriptis samal ülesandel, on see juba $env:SYSTEM_ACCESSTOKEN. Kui, jumal aidaku, soovite seda muutuja kasutada mõnel kaugmasinal, kasutades PowerShelli ülesandeid sihttarvutites, peate selle edastama skripti argumendina, kasutades param. Bashis on see lihtsam; seda saab lihtsalt edasi anda kasutades argumenti ja süntaksit $SYSTEM_ACCESSTOKEN.

Samad reeglid ei kehti teie enda muutuja kohta, siin vastutate juba süntaksi eest. Muutujate määramine on võimalik kohalikult igas ülesandes.

Või globaalsetes muutujate hoidlas, ja seejärel neid hoidlast linkida. Väga mugav.

Boonusena sellele, kui muutujad on tõeliselt salajased, saab neid hoida Azure'i pilves nimega Azure Vault, ning Vault'i saab projekti linkida Library's.

Üldiselt on muutujatega kõik selge, pipelines saab neid käsitsi iga käivituse jaoks seadistada, kuid release'is sellist funktsionaalsust ei ole. Vaadata, mida te pipeline'i edastate, saab veel kord agentide alguse logides, kuid arvestage, et need on seal juba muundatud kujul.

Dünaamilised muutujad

Kõige huvitavam algab siis, kui soovime mingit väärtust ühes etapis saada ja see järgmisse edastada.

Sellist funktsionaalsust pole meile toimetatud. Kuid meie käed ei ole igavuseks ja Google'i abil leidsime lahenduse. Tänu Jumalale, et Azure DevOps'il on API, mis võimaldab meil teha natuke rohkem, kui liideses joonistatud.

Nii et meil on vaja globaalseid muutujaid uuendava kutse, mille me teeme otse pipeline'i seest. Aadress saadakse keskkonna muutujatest, millest dokumentatsioonis ei ole sõnagi, nagu eelnevalt mainitud. Te saate neid ise seadistada või, noh, kõvakuvale kui asi kinni pannakse.

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

Seame muutuja tühjaks, mida tahame edastada, määrame Scope — Release

Näiteks teeme mingi juhuslik väärtuste generaatori. Pange tähele, kuidas muutujat käesolevas etapis deklareeritakse, selline funktsionaalsus on nüüd tööle pandud.

Järgmises etapis edastame muutuja skriptile, jah, jah, otse ei saa, see peab minema argumendi kaudu.

Skript peidiku all

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

Või

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

Kahesõnaliselt, meie skript võtab sisendina muutuja myVar ja kasutades API'd paneb selle muutuja väärtuse stageVar'i. Järgmises etapis saame kasutada süsteemimuutujate süntaksit selle vaatamiseks.

Näide on üsna lihtne, kuid funktsionaalsus avab meile häid võimalusi, koos minu varasema artikkel, kui me saame luua virtuaalse masina testimise esimeses etapis, teha sellega mingid manipulatsioonid edasi, sealjuures korraga mitu. Ja lõpp-etapiks selle hävitamine. Praegu jooksutame toote automaatkatseid iga kord värsketel virtuaalmasinatel. Arvestades, et nad elavad umbes 10 minutit, maksab see penni.

Järgmises artiklis, kui vajadus tekib, räägin YAML pipeline'idest, seal on viimase aja jooksul päris palju huvitavaid uuendusi.

Allikas: habr.com