Kontynuujemy naszą recenzję wspaniałego narzędzia do programowania dla systemu Windows i nie tylko, Azure DevOps. Tym razem, po wielu wycierpieniach ze zmiennymi środowiskowymi, zdecydowałem się umieścić całe doświadczenie w jednym artykule.
Począwszy od tego, że mają one inną składnię dla każdego środowiska wykonawczego, a skończywszy na braku standardowej możliwości przenoszenia zmiennych z jednego etapu potoku na drugi.
Zastrzegam, że główne przykłady będą na Release Pipelines, bo YAML jeszcze tam nie dotarł, a potrzebuję funkcjonalności wielu etapów i wielu artefaktów. Wydaje się, że stało się to dostępne w zwykłych Pipelines, co praktycznie dorównuje im funkcjonalnością. W Pipelines YAML dodaliśmy małą graficzną podpowiedź do reprezentacji tekstowej z parametrami, które można ustawić. Jest to bardzo wygodne, nie trzeba przeglądać dokumentacji każdego modułu. Ale opiszę to w następnym artykule, ale na razie tutaj jest obraz samej innowacji.
Przechowywanie i użytkowanie
Zacznijmy od tego, że w systemie mamy zmienne domyślne. Zaczynają się, w zależności od ich pochodzenia, od słów Release, System itp. Pełna lista (jak się okazuje nie) dostępna jest pod adresem . Całą schizofrenię ze składnią ilustruje przykład z poniższej dokumentacji. Ta sama zmienna ma trzy reprezentacje, w zależności od tego, gdzie ją nazwiemy.
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)Jeśli ustawisz zmienną na agencie, na którym wykonywane jest zadanie, będzie to $(System.AccessToken). Jeśli chcesz użyć go w skrypcie PowerShell na tym samym agencie, będzie to już $env:SYSTEM_ACCESSTOKEN. Jeśli, nie daj Boże, chcesz użyć tej zmiennej na jakimś zdalnym hoście za pomocą zadania PowerShell na komputerach docelowych, musisz przekazać to poprzez argument do skryptu za pomocą . Z bashem jest to prostsze, możesz po prostu przekazać go do środka, używając argumentu i składni $SYSTEM_ACCESSTOKEN.
Te same prawa nie dotyczą twoich własnych zmiennych; tutaj jesteś już odpowiedzialny za składnię. Zmienne można ustawić lokalnie w każdym zadaniu.
Lub globalnie do magazynu zmiennych, a następnie połącz je ze sklepem. Bardzo wygodnie.
Jako bonus, jeśli zmienne są bardzo tajne, można je przechowywać w chmurze Azure w magazynie o nazwie Azure Vault; możesz połączyć Vault z projektem w Bibliotece.
Ogólnie rzecz biorąc, ze zmiennymi wszystko jest jasne, w potokach nadal można je ustawić ręcznie dla każdego uruchomienia, w wersji nie ma takiej funkcjonalności. Możesz ponownie zobaczyć, co przesyłasz do potoku w dziennikach inicjowania agenta, ale pamiętaj, że są one już tam w przekonwertowanej formie.
Zmienne dynamiczne
Zabawa zaczyna się wtedy, gdy chcemy otrzymać jakąś wartość w jednym etapie i przekazać ją na kolejny.
Nie zapewniono nam takiej funkcjonalności. Ale nasze ręce nie służą do nudy i przy pomocy Google znaleziono rozwiązanie. Dzięki Bogu, Azure DevOps ma API, które pozwala nam zrobić trochę więcej niż to, co zostało przedstawione w interfejsie.
Będziemy więc potrzebować wywołania aktualizacji zmiennych globalnych, co zrobimy bezpośrednio z poziomu potoku. Adres pobierany jest ze zmiennych środowiskowych, tych samych, o których nie ma ani słowa w dokumentacji, jak wspomniano wcześniej. Możesz je ustawić samodzielnie lub co więcej, zakodować je na stałe, jeśli zamkną sklep.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )Ustawiamy pustą wartość zmiennej, którą chcemy przekazać, ustawiamy Scope - Release
Na przykład tworzymy generator wartości losowych. Zwróć uwagę na składnię deklarowania zmiennej na tym etapie, taka funkcjonalność została wprowadzona.
W kolejnym kroku przekazujemy zmienną do skryptu, tak, tak, bezpośrednio się nie da, trzeba to zrobić poprzez argument.
Skrypt pod spoilerem
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))
#endregionLub
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_URLKrótko mówiąc, nasz skrypt przyjmuje zmienną myVar jako dane wejściowe i używa interfejsu API, aby umieścić wartość tej zmiennej w stageVar. W następnym kroku, korzystając ze składni zmiennej systemowej, możemy się temu przyjrzeć.
Przykład jest dość prosty, ale funkcjonalność otwiera przed nami dobre możliwości, oprócz moich poprzednich , kiedy już na pierwszym etapie testów będziemy mogli stworzyć maszynę wirtualną, wykonać na niej dalsze manipulacje i kilka równolegle. Ostatnim etapem jest jego zniszczenie. Teraz za każdym razem przeprowadzamy autotesty produktu na świeżych maszynach wirtualnych. Biorąc pod uwagę, że żyją około 10 minut, kosztuje to grosz.
W następnym artykule, jeśli zajdzie taka potrzeba, opowiem o rurociągach YAML, ostatnio pojawiło się tam sporo ciekawych innowacji.
Źródło: www.habr.com