Uzante variablojn en Azure DevOps-duktoj

Ni daŭrigas nian revizion pri mirinda ilo por disvolviĝo por Vindozo kaj pli, Azure DevOps. Ĉi-foje, multe suferinte pri mediaj variabloj, mi decidis meti la tutan sperton en unu artikolon.

Komencante de la fakto ke ili havas malsaman sintakson por ĉiu ekzekutmedio, finiĝante kun la manko de norma kapablo translokigi variablojn de unu stadio de la dukto al alia.

Mi rezervos, ke la ĉefaj ekzemploj estos en Release Pipelines, ĉar YAML ankoraŭ ne alvenis tie, kaj mi bezonas la funkciecon de multaj stadioj kaj multaj artefaktoj. Ĉi tio, ŝajnas, fariĝis havebla en regulaj Duktoj, kiu preskaŭ egalas ilin en funkcieco. En Pipelines YAML, ni aldonis malgrandan grafikan konsileton al la teksta prezento kun parametroj agordeblaj. Ĝi estas tre oportuna; vi ne devas trarigardi la dokumentadon por ĉiu modulo. Sed mi priskribos ĉi tion en la sekva artikolo, sed nuntempe ĉi tie estas bildo de la novigo mem.

Stokado kaj uzo

Ni komencu per tio, ke ni havas defaŭltajn variablojn en la sistemo. Ili komenciĝas, depende de sia origino, per la vortoj Liberigo, Sistemo ktp. La plena listo (kiel ĝi rezultas, ne), estas havebla ĉe dokumentado. Ĉiu skizofrenio kun sintakso estas ilustrita per ekzemplo el la dokumentado malsupre. La sama variablo havas tri prezentojn, depende de kie ni nomas ĝin.

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)

Se vi fiksas variablon sur la agento sur kiu la tasko estas efektivigita, ĝi estas $(System.AccessToken). Se vi volas uzi ĝin ene de powershell-skripto ĉe la sama agento, ĝi jam estos $env:SYSTEM_ACCESSTOKEN. Se vi, Dio malpermesu, volas uzi ĉi tiun variablon en iu fora gastiganto uzante la taskon PowerShell sur celaj maŝinoj, vi devas pasi ĉi tion tra argumento al la skripto uzante mia mono. Kun bash ĝi estas pli simpla, vi povas simple pasi ĝin interne uzante la argumenton kaj sintakson $SYSTEM_ACCESSTOKEN.

La samaj leĝoj ne validas por viaj propraj variabloj; ĉi tie vi jam respondecas pri la sintakso. Variabloj povas esti fiksitaj loke en ĉiu tasko.

Aŭ tutmonde al la varia vendejo, kaj poste ligu ilin de la vendejo. Tre komforte.

Kiel gratifiko, se la variabloj estas tre sekretaj, ili povas esti konservitaj en la Azure-nubo en stokado nomata Azure Vault; vi povas ligi Vault al la projekto en la Biblioteko.

Ĝenerale, ĉio estas klara kun variabloj; en duktoj ili ankoraŭ povas esti agorditaj permane por ĉiu lanĉo; en eldono ne ekzistas tia funkcieco. Vi povas vidi tion, kion vi transdonas al la dukto denove en la protokoloj pri inicialigo de agentoj, sed memoru, ke ili jam estas tie en konvertita formo.

Dinamikaj Variabloj

La amuzo komenciĝas kiam ni volas ricevi iom da valoro en unu etapo kaj pasi ĝin al la sekva.

Ni ne ricevis tiajn funkciojn. Sed niaj manoj ne estas por enui kaj helpe de Guglo oni trovis solvon. Dankon al Dio, Azure DevOps havas API, kiu permesas al ni fari iom pli ol tio, kio estis prezentita en la interfaco.

Do, ni bezonos alvokon por ĝisdatigi tutmondajn variablojn, kion ni faros rekte de ene de la dukto. La adreso estas prenita de mediovariabloj, la samaj pri kiuj ne estas vorto en la dokumentado, kiel antaŭe menciite. Vi povas agordi ilin mem aŭ, kio estas pli, malmola kodi ilin se ili fermas la butikon.

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

Ni fiksas la malplenan valoron de la variablo, kiun ni volas translokigi, agordu Scope - Release

Ekzemple, ni faras iun hazardan valorgeneratoron. Atentu la sintakson deklari variablon ene de ĉi tiu stadio; ĉi tiu funkcio estis enkondukita.

En la sekva paŝo, ni pasas la variablon al la skripto, jes, jes, ĝi ne eblas rekte, ĝi devas esti per argumento.

Skripto sub 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))
#endregion

Aŭ

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

Resume, nia skripto prenas la variablon myVar kiel enigaĵon kaj uzas la API por meti la valoron de ĉi tiu variablo en stageVar. En la sekva paŝo, uzante sisteman variablo sintakson, ni povas rigardi ĝin.

La ekzemplo estas sufiĉe simpla, sed la funkcieco malfermas al ni bonajn ŝancojn, krom mia antaŭa artikoloj, kiam ni povas krei virtualan maŝinon ĉe la unua etapo de testado, fari kelkajn pliajn manipuladojn kun ĝi, kaj plurajn paralele. Kaj la fina etapo estas detrui ĝin. Nun ni faras aŭtomatajn provojn de la produkto ĉiufoje sur freŝaj virtualaj maŝinoj. Konsiderante, ke ili vivas ĉirkaŭ 10 minutojn, ĝi kostas unu pencon.

En la sekva artikolo, se necese, mi parolos pri YAML-duktoj; estis sufiĉe da interesaj novigoj tie lastatempe.

fonto: www.habr.com