Muuttujien käyttäminen Azure DevOps -putkissa

Jatkamme tarkasteluamme upeasta Windows- ja muiden kehitystyökalujen, Azure DevOps -työkalusta. Tällä kertaa, kun olen kärsinyt paljon ympäristömuuttujista, päätin koota kaikki kokemukset yhteen artikkeliin.

Alkaen siitä tosiasiasta, että niillä on erilainen syntaksi jokaiselle suoritusympäristölle, ja päättyy siihen, ettei ole vakiokykyä siirtää muuttujia liukuhihnan yhdestä vaiheesta toiseen.

Teen varauksen, että pääesimerkit ovat Release Pipelinesissä, koska YAML ei ole vielä päässyt sinne ja tarvitsen monien vaiheiden toimivuutta ja monia artefakteja. Tämä näyttää tulleen saataville tavallisissa Pipelinesissä, mikä käytännössä vastaa niitä toiminnaltaan. Pipelines YAML:ssä lisäsimme tekstin esitykseen pienen graafisen työkaluvihjeen, jossa parametrit voidaan asettaa. Se on erittäin kätevää; sinun ei tarvitse käydä läpi jokaisen moduulin dokumentaatiota. Mutta kerron tämän seuraavassa artikkelissa, mutta tässä on nyt kuva itse innovaatiosta.

Varastointi ja käyttö

Aloitetaan siitä, että järjestelmässä on oletusmuuttujia. Ne alkavat alkuperästään riippuen sanoilla Release, System jne. Täydellinen luettelo (kuten käy ilmi, ei) on saatavilla osoitteessa dokumentointi. Kaikkea syntaksia skitsofreniaa havainnollistaa esimerkillä alla olevasta dokumentaatiosta. Samalla muuttujalla on kolme esitystapaa riippuen siitä, missä sitä kutsutaan.

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)

Jos asetat muuttujan agentille, jolla tehtävä suoritetaan, se on $(System.AccessToken). Jos haluat käyttää sitä Powershell-skriptin sisällä samassa agentissa, se on jo $env:SYSTEM_ACCESSTOKEN. Jos sinä, varjelkoon, haluat käyttää tätä muuttujaa jollakin etäisännällä käyttämällä PowerShell on kohdekoneissa -tehtävää, sinun on välitettävä tämä argumentin kautta komentosarjalle käyttämällä rahani. Bashilla se on yksinkertaisempaa, voit yksinkertaisesti siirtää sen sisään argumentilla ja syntaksilla $SYSTEM_ACCESSTOKEN.

Samat lait eivät päde omiin muuttujiisi, vaan tässä olet jo vastuussa syntaksista. Muuttujat voidaan asettaa paikallisesti jokaisessa tehtävässä.

Tai maailmanlaajuisesti muuttujakauppaan ja linkitä ne sitten kaupasta. Erittäin mukavasti.

Bonuksena, jos muuttujat ovat hyvin salaisia, ne voidaan tallentaa Azure-pilveen Azure Vault -nimiseen tallennustilaan; voit linkittää Holvin projektiin kirjastossa.

Yleensä muuttujien kanssa kaikki on selvää; putkissa ne voidaan edelleen asettaa manuaalisesti jokaiselle laukaisulle; julkaisussa tällaista toimintoa ei ole. Voit nähdä, mitä siirrät liukuhihnaan uudelleen agentin alustuslokeissa, mutta muista, että ne ovat jo siellä muunnetussa muodossa.

Dynaamiset muuttujat

Hauskuus alkaa siitä, kun haluamme saada arvoa yhdessä vaiheessa ja siirtää sen seuraavaan.

Meille ei tarjottu tällaista toimintoa. Mutta kätemme eivät ole ikävystymistä varten ja Googlen avulla löydettiin ratkaisu. Luojan kiitos, Azure DevOpsissa on API, jonka avulla voimme tehdä hieman enemmän kuin mitä käyttöliittymässä on kuvattu.

Tarvitsemme siis kutsun päivittää globaalit muuttujat, minkä teemme suoraan putkistosta. Osoite on otettu ympäristömuuttujista, samoista, joista ei ole sanaakaan dokumentaatiossa, kuten aiemmin mainittiin. Voit asettaa ne itse tai, mikä parasta, koodata ne, jos ne sulkevat kaupan.

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

Asetamme siirrettävän muuttujan tyhjän arvon, asetamme Scope - Release

Teemme esimerkiksi jonkin satunnaisarvogeneraattorin. Kiinnitä huomiota muuttujan ilmoittamisen syntaksiin tässä vaiheessa; tämä toiminto otettiin käyttöön.

Seuraavassa vaiheessa siirrämme muuttujan skriptille, kyllä, kyllä, se ei ole mahdollista suoraan, sen täytyy tapahtua argumentin kautta.

Käsikirjoitus spoilerin alla

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

tai

Kemut

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

Lyhyesti sanottuna, komentosarjamme ottaa muuttujan myVar syötteenä ja käyttää API:ta tämän muuttujan arvon lisäämiseen stageVariin. Seuraavassa vaiheessa, käyttämällä järjestelmämuuttujan syntaksia, voimme tarkastella sitä.

Esimerkki on melko yksinkertainen, mutta toiminnallisuus avaa meille hyviä mahdollisuuksia edelliseni lisäksi artikkeleita, kun voimme luoda virtuaalikoneen testauksen ensimmäisessä vaiheessa, suorittaa sen kanssa joitain lisäkäsittelyjä ja useita rinnakkain. Ja viimeinen vaihe on tuhota se. Nyt suoritamme tuotteen automaattisia testejä joka kerta tuoreissa virtuaalikoneissa. Kun otetaan huomioon, että he elävät noin 10 minuuttia, se maksaa penniäkään.

Seuraavassa artikkelissa kerron tarvittaessa YAML-putkistosta, siellä on ollut viime aikoina aika paljon mielenkiintoisia innovaatioita.

Lähde: will.com