שימוש במשתנים בצינורות Azure DevOps

אנו ממשיכים בסקירה של כלי נפלא לפיתוח עבור Windows ועוד, Azure DevOps. הפעם, לאחר שסבלתי הרבה עם משתני סביבה, החלטתי להכניס את כל הניסיון למאמר אחד.

החל מהעובדה שיש להם תחביר שונה לכל סביבת ביצוע, וכלה בהיעדר יכולת סטנדרטית להעביר משתנים משלב אחד של הצינור למשנהו.

אני אעשה הסתייגות שהדוגמאות העיקריות יהיו ב- Release Pipelines, כי YAML עדיין לא הגיעה לשם, ואני צריך את הפונקציונליות של שלבים רבים וחפצים רבים. זה, כך נראה, הפך זמין ב-Pipelines רגילים, אשר כמעט משתווה להם בפונקציונליות. ב-Pipelines YAML, הוספנו הסבר כלים גרפי קטן לייצוג הטקסט עם פרמטרים שניתן להגדיר. זה מאוד נוח; אתה לא צריך לעבור על התיעוד עבור כל מודול. אבל אתאר זאת במאמר הבא, אבל לעת עתה הנה תמונה של החידוש עצמו.

אחסון ושימוש

נתחיל מזה שיש לנו משתני ברירת מחדל במערכת. הם מתחילים, בהתאם למקורם, במילים Release, System וכו'. הרשימה המלאה (כפי שמסתבר, לא), זמינה בכתובת תיעוד. כל סכיזופרניה עם תחביר מומחשת על ידי דוגמה מהתיעוד שלהלן. לאותו משתנה יש שלושה ייצוגים, תלוי איפה אנחנו קוראים לו.

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)

אם אתה מגדיר משתנה בסוכן שעליו מבוצעת המשימה, הוא $(System.AccessToken). אם אתה רוצה להשתמש בו בתוך סקריפט powershell על אותו סוכן, זה כבר יהיה $env:SYSTEM_ACCESSTOKEN. אם אתה, חלילה, רוצה להשתמש במשתנה זה על מארח מרוחק כלשהו באמצעות משימת PowerShell במכונות היעד, עליך להעביר זאת דרך ארגומנט לסקריפט באמצעות להפסיק. עם bash זה פשוט יותר, אתה יכול פשוט להעביר את זה פנימה באמצעות הארגומנט והתחביר $SYSTEM_ACCESSTOKEN.

אותם חוקים אינם חלים על המשתנים שלך; כאן אתה כבר אחראי על התחביר. ניתן להגדיר משתנים באופן מקומי בכל משימה.

או באופן גלובלי לחנות המשתנה, ולאחר מכן קשר אותם מהחנות. בנוחות רבה.

כבונוס, אם המשתנים סודיים מאוד, ניתן לאחסן אותם בענן Azure באחסון שנקרא Azure Vault; ניתן לקשר את Vault לפרויקט בספרייה.

באופן כללי, הכל ברור עם משתנים; בצינורות עדיין ניתן להגדיר אותם באופן ידני עבור כל השקה; בשחרור אין פונקציונליות כזו. אתה יכול לראות מה אתה מעביר לצינור שוב ביומני האתחול של הסוכן, אבל זכור שהם כבר נמצאים שם בצורה מומרת.

משתנים דינמיים

הכיף מתחיל כשאנחנו רוצים לקבל ערך כלשהו בשלב אחד ולהעביר אותו לשלב הבא.

לא סופקה לנו פונקציונליות כזו. אבל הידיים שלנו לא לשעמום ובעזרת גוגל נמצא פתרון. תודה לאל, ל-Azure DevOps יש API שמאפשר לנו לעשות קצת יותר ממה שתואר בממשק.

לכן, נצטרך קריאה לעדכון משתנים גלובליים, אותה נעשה ישירות מתוך הצינור. הכתובת לקוחה ממשתני סביבה, אותם אלה שאין עליהם מילה בתיעוד, כפי שהוזכר קודם לכן. אתה יכול להגדיר אותם בעצמך או, מה עוד, להקפיד עליהם אם הם סוגרים את החנות.

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

אנחנו מגדירים את הערך הריק של המשתנה שברצוננו להעביר, מגדירים Scope - Release

לדוגמה, אנו מייצרים איזה מחולל ערכים אקראי. שימו לב לתחביר של הכרזה על משתנה בשלב זה; פונקציונליות זו הוצגה.

בשלב הבא, נעביר את המשתנה לסקריפט, כן, כן, זה לא אפשרי ישירות, זה חייב להיות דרך ארגומנט.

התסריט תחת ספוילר

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

או

לְהַכּוֹת

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

בקיצור, הסקריפט שלנו לוקח את המשתנה myVar כקלט ומשתמש ב-API כדי להכניס את הערך של המשתנה הזה לתוך stageVar. בשלב הבא, באמצעות תחביר משתנה מערכת, נוכל להסתכל עליו.

הדוגמה די פשוטה, אבל הפונקציונליות פותחת בפנינו הזדמנויות טובות, בנוסף לקודמים שלי מאמרים, כאשר אנו יכולים ליצור מכונה וירטואלית בשלב הראשון של הבדיקה, לבצע איתה כמה מניפולציות נוספות, וכמה במקביל. והשלב האחרון הוא להרוס אותו. כעת אנו מפעילים בדיקות אוטומטיות של המוצר בכל פעם במכונות וירטואליות טריות. בהתחשב בכך שהם חיים בערך 10 דקות, זה עולה אגורה.

במאמר הבא, במידת הצורך, אדבר על צינורות YAML; לאחרונה היו שם לא מעט חידושים מעניינים.

מקור: www.habr.com