🥇Muudatused Azure DevOps torudes

Jätkame suurepärase Windowsi arendustööriista ülevaatamist, Azure DevOps. Seekord, pärast keskkonnamuutujatega vaeva nägemist, otsustasin kogu oma kogemuse ühe artikli sisse koondada.

Alustame sellest, et igas jooksukeskkonnas on neil erinev süntaks, ning lõpetame selle puudumisega, et muuta muutujaid ühest etappist teise pipeline'is.

Tulen välja, et peamised näited on Release Pipelines, kuna YAML ei ole sinna veel jõudnud ja mul on vaja funktsionaalsust mitmest etapist ja mitmest artefaktist. See, nagu tundub, on nüüdseks tavapärastes Pipelines saadaval, mis peaaegu võrdsustas nende funktsionaalsust. Pipelines YAML'i on täiustatud ja lisatud tekstipresentatsioonile väike graafiline näpunäide parameetrite kohta, mida saab määrata. Väga mugav, ei pea iga mooduli jaoks dokumentatsiooni vaatama. Kuid seda kirjeldan järgmises artiklis, ja siinkohal on pilt uuest uuendusest.

Salvestamine ja kasutamine

Alustame sellest, et süsteemis on meil vaikimisi muutujad. Need algavad, sõltuvalt päritolust, sõnadest Release, System jne. Täielik nimekiri (nagu selgub, puudub) on saadaval dokumentatsioonis. Kogu süntaksit illustreerib allpool olev näide dokumentatsioonist. Ühel ja samal muutujal on kolm esitamist, sõltuvalt sellest, kust me seda kutsume.

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 ülesande täitmiseks kasutataval agentil, on see $(System.AccessToken). Kui soovite seda kasutada powershell skriptis samal agendil, on see juba $env:SYSTEM_ACCESSTOKEN. Kui teil on, jumal hoia, soov kasutada seda muutujat mõnes kaugmasinas, kasutades PowerShelli ülesannet sihtmasinatel, peate selle edastama argumendina skripti juurde, kasutades param. Bashis on lihtsam, saab lihtsalt edastada, kasutades argumenti ja süntaksit $SYSTEM_ACCESSTOKEN.

Samad reeglid ei laiene teie enda muutujaile, siin kannate juba vastutust süntaksi eest. Muutujad saab määrata kohalikult igas ülesandes.

Või globaalsetes muutuja ladudes, ja seejärel linkida neid varude kaudu. Väga mugav.

Booniksena, kui muutujaid on tõeliselt salajased, saab neid säilitada Azure'i pilves nimega Azure Vault; Vaulti saab linkida projekti raamatukogus.

Kokkuvõttes on muutujatega kõik selge, pipelines'i puhul saab neid veel käsitsi igaks käivitamiseks seadistada, release'is sellist funktsionaalsust pole. Vaadata, mida te pipelines'isse edastate, saab veel kord agentide alguslogidest, kuid pidage meeles, et seal on need juba muudetud kujul.

Dünaamilised muutujad

Huvi hakkab tõeliselt tõusma, kui soovime saada mingit väärtust ühes etapis ja edastada selle järgmisse.

Sellist funktsionaalsust meile ei pakutud. Kui aga meie käed ei ole külmad, leidsime Google'i abiga lahenduse. Tõeliselt tänu Azure DevOps'ile on olemas API, mis võimaldab meil teha natuke rohkem, kui liideses joonistatud.

Seega vajame globaalsete muutujate värskendamise kõnet, mille teeme otse pipelines'ist. Aadress võetakse keskkonnamuutujatest, neist, millest dokumentatsioonis ei räägita, nagu eelnevalt mainitud. Saate need ise seadistada või, mis seal ikka, hardcode'ida, kui elu ei anna.

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

Seame tühjaks muutuja, mille tahame üle anda, määrame ulatuse — Väljalaskmine

Näitena loome juhusliku väärtuste generaatori. Pöörake tähelepanu muutuja deklareerimise süntaksile selle etapi jooksul, selline funktsionaalsus on sisse toodud.

Järgmises etapis edastame muutuja skriptile, jah, otseselt ei saa, tuleb läbi argumendi.

Skript peidetud aluses

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 Testi ID: ${INPUT_VAR}

RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}/_apis/release/releases/${RELEASE_RELEASEID}?api-version=5.0"

echo Väljalaskmise 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

Kokkuvõttes, meie skript võtab sisendina muutuja myVar ja kasutades API-d, asetab selle muutuja väärtuse stageVar-i. Järgmises etapis, kasutades süsteemsete muutujate süntaksit, saame seda näha.

Näide on üsna lihtne, kuid funktsionaalsus avab meile häid võimalusi, koos minu eelmisega. artikkel, kui me saame luua esimese etapi testimise jaoks virtuaalmasina, teha sellel mõningaid toiminguid ning seejärel samal ajal mitme masinaga. Lõppfaas on selle hävitamine. Praegu toimub meie toote automaattestide käitamine iga kord värsketel virtuaalmasinatel. Arvestades, et need eksisteerivad 10 minutit, maksab see vähe.

Järgmises artiklis, kui on vajadus, räägin YAML torudest, seal on viimase ajal palju huvitavaid uuendusi.

Allikas: habr.com

Muutuja kasutamine Azure DevOps-i töövoogudes

Salvestamine ja kasutamine

Dünaamilised muutujad