מדריך ל-CI/CD ב-GitLab למתחילים (כמעט) מוחלטים

או איך להשיג תגים יפים לפרויקט שלך בערב אחד של קידוד קל

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

מאמר זה ידריך אותך דרך ההגדרה הבסיסית של אינטגרציה ואספקה ​​מתמשכת עבור פרויקט ספריית כיתה .Net Core ב-GitLab, פרסום תיעוד לדפי GitLab ודחיפת חבילות בנויות לפיד פרטי ב-Azure DevOps.

קוד VS שימש כסביבת הפיתוח עם ההרחבה זרימת עבודה של GitLab (לאימות קובץ ההגדרות ישירות מסביבת הפיתוח).

הקדמה קצרה

CD - זה כשרק דחפת, והכל כבר נפל על הלקוח?

מה זה CI / CD ולמה אתה צריך את זה - אתה יכול בקלות לחפש בגוגל. מצא תיעוד מלא על הגדרת צינורות ב-GitLab גם קל. כאן אתאר בקצרה ובמידת האפשר ללא פגמים את תהליך המערכת ממעוף הציפור:

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

לפיכך, יש לנו:

• pipeline - אוסף של משימות מאורגנות לשלבים בהם ניתן לבנות, לבדוק, חבילה קוד, לפרוס בנייה מוגמרת לשירות ענן וכו',
• שלב (שלב) - יחידת ארגון צינור, מכילה משימה אחת ומעלה,
• משימה (עבודה) היא יחידת עבודה בצנרת. הוא מורכב מתסריט (חובה), תנאי השקה, הגדרות לפרסום/אחסון חפצים במטמון ועוד הרבה יותר.

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

לפני שמתחילים: למה?

• למה Gitlab?

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

• למה לא Azure DevOps Pipelines?

מכיוון ששם ההגדרה היא אלמנטרית - ידע בשורת הפקודה אפילו לא נדרש. אינטגרציה עם ספקי git חיצוניים - בכמה קליקים, ייבוא ​​של מפתחות SSH כדי לשלוח commits למאגר - גם ה-pipeline מוגדר בקלות אפילו לא מתבנית.

עמדת מוצא: מה יש לך ומה אתה רוצה

יש לנו:

• מאגר ב-GitLab.

אנחנו רוצים:

• הרכבה ובדיקה אוטומטית עבור כל בקשת מיזוג,
• בניית חבילות לכל בקשת מיזוג ודחיפה למאסטר, בתנאי שיש שורה מסוימת בהודעת ה-commit,
• שליחת חבילות בנויות לפיד פרטי ב-Azure DevOps,
• הרכבה של תיעוד ופרסום בדפי GitLab,
• תגים!11

הדרישות המתוארות נופלות באופן אורגני על מודל הצינור הבא:

• שלב 1 - הרכבה
  • אנו אוספים את הקוד, מפרסמים את קבצי הפלט כחפצים
• שלב 2 - בדיקה
  • אנו מקבלים חפצים משלב הבנייה, מפעילים בדיקות, אוספים נתוני כיסוי קוד
• שלב 3 - הגשה
  • משימה 1 - בנה את חבילת ה-nuget ושלח אותה ל-Azure DevOps
  • משימה 2 - אנו אוספים את האתר מ-xmldoc בקוד המקור ומפרסמים אותו בדפי GitLab

בואו נתחיל!

איסוף התצורה

הכנת חשבונות

1. צור חשבון ב Microsoft Azure

2. לך ל Devure של תכלת

3. אנחנו יוצרים פרויקט חדש

   1. שם - כל
   2. נראות - כל
      

4. כאשר תלחץ על כפתור צור, הפרוייקט יווצר ותועבר לדף שלו. בעמוד זה, תוכל להשבית תכונות מיותרות על ידי מעבר להגדרות הפרויקט (קישור תחתון ברשימה משמאל -> סקירה כללית -> בלוק שירותי Azure DevOps)
   

5. עבור אל Atrifacts, לחץ על צור עדכון

   1. הזן את שם המקור
   2. בחר נראות
   3. בטל את הסימון כלול חבילות ממקורות ציבוריים נפוצים, כדי שהמקור לא יהפוך לשבוט של dump nuget
      

6. לחץ על התחבר להזנה, בחר ב-Visual Studio, העתק את המקור מהגוש הגדרת מכונה
   

7. עבור להגדרות החשבון, בחר אסימון גישה אישי
   

8. צור אסימון גישה חדש

   1. שם - שרירותי
   2. ארגון - עדכני
   3. תקף לשנה לכל היותר
   4. היקף - אריזה/קריאה וכתיבה
      

9. העתק את האסימון שנוצר - לאחר סגירת החלון המודאלי, הערך לא יהיה זמין

10. עבור להגדרות המאגר ב-GitLab, בחר את הגדרות ה-CI / CD
    

11. הרחב את גוש המשתנים, הוסף אחד חדש

    1. שם - כל אחד ללא רווחים (יהיה זמין במעטפת הפקודה)
    2. ערך - אסימון גישה מסעיף 9
    3. בחר משתנה מסכה
       

זה משלים את התצורה המוקדמת.

הכנת מסגרת התצורה

כברירת מחדל, תצורת CI/CD ב-GitLab משתמשת בקובץ .gitlab-ci.yml מהשורש של המאגר. אתה יכול להגדיר נתיב שרירותי לקובץ זה בהגדרות המאגר, אך במקרה זה אין צורך בכך.

כפי שניתן לראות מהסיומת, הקובץ מכיל תצורה בפורמט YAML. התיעוד מפרט אילו מפתחות ניתן להכיל ברמה העליונה של התצורה, ובכל אחת מהרמות המקוננות.

ראשית, נוסיף קישור לתמונת ה-docker בקובץ התצורה, בה יבוצעו המשימות. בשביל זה אנחנו מוצאים דף תמונות .Net Core ב- Docker Hub. בתוך GitHub יש מדריך מפורט באיזו תמונה לבחור למשימות שונות. תמונה עם .Net Core 3.1 מתאימה לנו לבנות, אז אתם מוזמנים להוסיף את השורה הראשונה לתצורה

image: mcr.microsoft.com/dotnet/core/sdk:3.1

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

השלב הבא הוא להוסיף שלבשל. כברירת מחדל, GitLab מגדיר 5 שלבים:

• .pre - מבוצע עד כל השלבים,
• .post - מבוצע לאחר כל השלבים,
• build - ראשון אחרי .pre שלב,
• test - שלב שני,
• deploy - השלב השלישי.

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

stages:
  - build
  - test
  - deploy

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

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

נותר להוסיף לפחות משימה אחת כדי שכאשר ה-commits יישלחו, ה-pipeline יתחיל. לעת עתה, בואו נוסיף משימה ריקה להדגמה:

dummy job:
  script:
    - echo ok

אנחנו מתחילים אימות, מקבלים הודעה שהכל בסדר, אנחנו מתחייבים, אנחנו דוחפים, אנחנו מסתכלים על התוצאות באתר... ומקבלים שגיאת סקריפט - bash: .PSVersion: command not found. wtf?

הכל הגיוני - כברירת מחדל, רצים (האחראים על ביצוע סקריפטים של משימות ומסופקים על ידי GitLab) משתמשים bash כדי לבצע פקודות. אתה יכול לתקן זאת על ידי ציון מפורש בתיאור המשימה אילו תגים צריכים להיות לרץ הצינור המבצע:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

גדול! הצינור פועל כעת.

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

בואו נמשיך ליצור את שלד התצורה על ידי הוספת כל המשימות שתוארו לעיל:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

קיבלנו צינור לא פונקציונלי במיוחד, אבל בכל זאת נכון.

הגדרת טריגרים

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

ניתן להגדיר מסננים בשני פורמטים: רק/למעט и כללי. בקצרה, only/except מאפשר לך להגדיר מסננים לפי טריגרים (merge_request, למשל - מגדיר את המשימה לביצוע בכל פעם שנוצרת בקשת pull ובכל פעם שנשלחות commits לסניף שהוא המקור בבקשת המיזוג) ושמות סניפים (כולל שימוש בביטויים רגולריים); rules מאפשר לך להתאים אישית קבוצה של תנאים ובאופן אופציונלי לשנות את תנאי ביצוע המשימה בהתאם להצלחת המשימות הקודמות (when ב- GitLab CI/CD).

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

ראשית, הבה נגדיר את משימת בניית הקוד על ידי הוספת כלל שפועל רק בבקשת מיזוג:

build job:
  # snip
  only:
    - merge_request

כעת הבה נגדיר את משימת האריזה להפעלת בקשת המיזוג ונוסיף התחייבויות למאסטר:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

כפי שאתה יכול לראות, הכל פשוט ופשוט.

אתה יכול גם להגדיר את המשימה להפעלה רק אם נוצרת בקשת מיזוג עם יעד ספציפי או ענף מקור ספציפי:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

בתנאים, אתה יכול להשתמש משתנים המופיעים כאן; כללים rules לא תואם את הכללים only/except.

הגדרת שמירת חפצים

במהלך משימה build job ניצור חפצים שניתן לעשות בהם שימוש חוזר במשימות הבאות. לשם כך, עליך להוסיף את הנתיבים לתצורת המשימה, את הקבצים שלאורכם תצטרך לשמור ולעשות שימוש חוזר במשימות הבאות, למפתח artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

נתיבים תומכים בתווים כלליים, מה שבהחלט מקל על הגדרתם.

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

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

אנחנו כותבים תסריטים

אולי, פעם, בגלקסיה רחוקה, רחוקה, בניית פרויקטים (כולל אלה ב-.net) משורת הפקודה הייתה כאב. עכשיו אתה יכול לבנות, לבדוק ולפרסם את הפרויקט ב-3 צוותים:

dotnet build
dotnet test
dotnet pack

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

1. אנחנו רוצים בניית שחרור, לא בניית באגים, אז אנחנו מוסיפים לכל פקודה -c Release
2. בעת הבדיקה, אנו רוצים לאסוף נתוני כיסוי קוד, ולכן עלינו לכלול מנתח כיסוי בספריות הבדיקה:
   1. הוסף את החבילה לכל ספריות הבדיקה coverlet.msbuild: dotnet add package coverlet.msbuild מתיקיית הפרויקט
   2. הוסף לפקודת הפעלת המבחן /p:CollectCoverage=true
   3. הוסף מפתח לתצורת משימת הבדיקה כדי לקבל תוצאות כיסוי (ראה להלן)
3. בעת אריזה של הקוד בחבילות nuget, הגדר את ספריית הפלט עבור החבילות: -o .

איסוף נתוני כיסוי קוד

לאחר הפעלת הבדיקות, Coverlet מדפיס סטטיסטיקות הפעלה לקונסולה:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

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

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

כאן אנו מקבלים נתונים סטטיסטיים מקו עם כיסוי קו כולל.

פרסם חבילות ותיעוד

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

ראשית, שקול לפרסם במקור החבילה:

1. אם לפרויקט אין קובץ תצורה של nuget (nuget.config), צור אחד חדש: dotnet new nugetconfig

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

2. בואו נוסיף מקור חבילה חדש לתצורה המקומית: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
   1. name - שם מקור מקומי, לא קריטי
   2. url - URL של המקור משלב "הכנת חשבונות", עמ' 6
   3. organization - שם הארגון ב-Azure DevOps
   4. gitlab variable - שם המשתנה עם אסימון הגישה שנוסף ל-GitLab ("הכנת חשבונות", עמ' 11). באופן טבעי, בפורמט $variableName
   5. -StorePasswordInClearText - פריצה כדי לעקוף את שגיאת הגישה נדחתה (אני לא הראשון שדרך על המגרפה הזו)
   6. במקרה של שגיאות, ייתכן שיהיה שימושי להוסיף -verbosity detailed
3. שליחת החבילה למקור: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
   1. אנחנו שולחים את כל החבילות מהספרייה הנוכחית, אז *.nupkg.
   2. name - מהשלב שלמעלה.
   3. key - כל שורה. ב-Azure DevOps, בחלון Connect to feed, הדוגמה היא תמיד הקו az.
   4. -skipduplicate - כאשר מנסים לשלוח חבילה שכבר קיימת ללא מפתח זה, המקור יחזיר שגיאה 409 Conflict; עם המפתח, השליחה תידלג.

עכשיו בואו נגדיר את יצירת התיעוד:

1. ראשית, במאגר, בענף המאסטר, אנו מאתחלים את פרויקט docfx. לשם כך, הפעל את הפקודה מהשורש docfx init ולהגדיר באופן אינטראקטיבי את הפרמטרים המרכזיים לתיעוד הבניין. תיאור מפורט של הגדרת הפרויקט המינימלית כאן.
   1. בעת הגדרת התצורה, חשוב לציין את ספריית הפלט ..public - GitLab כברירת מחדל לוקח את תוכן התיקיה הציבורית בשורש המאגר כמקור עבור Pages. כי הפרויקט ימוקם בתיקייה המקוננת במאגר - הוסף פלט לרמה למעלה בנתיב.
2. בואו נדחוף את השינויים ל-GitLab.
3. הוסף משימה לתצורת הצינור pages (מילה שמורה למשימות פרסום אתרים בדפי GitLab):
   1. תַסרִיט:
      1. nuget install docfx.console -version 2.51.0 - התקן docfx; הגרסה צוינה כדי להבטיח שנתיבי התקנת החבילה נכונים.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - איסוף תיעוד
   2. חפצי צומת:

pages:
  # snip
  artifacts:
    paths:
      - public

סטייה לירית על docfx

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

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

1. metadata.src.src: "../" - אנחנו עולים רמה אחת למעלה ביחס למיקום docfx.json, כי בתבניות, חיפוש בעץ הספריות לא עובד.
2. metadata.src.files: ["**/*.csproj"] - דפוס גלובלי, אנו אוספים את כל הפרויקטים של C # מכל הספריות.
3. metadata.src.exclude: ["*.tests*/**"] - דפוס גלובלי, אל תכלול הכל מתיקיות עם .tests בכותרת

רמה חלקית

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

Final .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

אם כבר מדברים על תגים

בגללם, אחרי הכל, הכל התחיל!

תגים עם סטטוסי צינור וכיסוי קוד זמינים ב-GitLab בהגדרות ה-CI/CD בגוש הצינורות של Gtntral:

יצרתי תג עם קישור לתיעוד בפלטפורמה shields.io - הכל די פשוט שם, אתה יכול ליצור תג משלך ולקבל אותו באמצעות בקשה.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts מאפשר לך גם ליצור תגים עבור חבילות עם הגרסה העדכנית ביותר. לשם כך, במקור באתר Azure DevOps, עליך ללחוץ על Create badge עבור החבילה שנבחרה ולהעתיק את סימון הסימון:

הוספת יופי

הדגשת קטעי תצורה נפוצים

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

כפי שניתן לראות מהגדרות המשימה, כולן דורשות את התג windows אצל הרץ, ומופעלות כאשר בקשת מיזוג נשלחת למאסטר/נוצר (למעט תיעוד). בואו נוסיף את זה לפרגמנט שבו נעשה שימוש חוזר:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

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

build job:
  <<: *common_tags
  <<: *common_only

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

ניהול גרסאות של חבילה

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

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

בואו נסכים שאם הודעת ה-commit מכילה שורה כמו release (v./ver./version) <version number> (rev./revision <revision>)?, אז ניקח את גרסת החבילה מהשורה הזו, נשלים אותה עם התאריך הנוכחי ונעביר אותה כארגומנט לפקודה dotnet pack. בהיעדר תור, פשוט לא נאסוף את החבילה.

הסקריפט הבא פותר את הבעיה הזו:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

הוספת סקריפט למשימה pack and deploy job ולצפות בהרכבת החבילות אך ורק בנוכחות מחרוזת נתונה בהודעת ה-commit.

בסך הכל

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

כמובן, GitLab CI / CD הוא הרבה יותר נרחב ורב-גוני ממה שהוא עשוי להיראות לאחר קריאת המדריך הזה - זה לא נכון בכלל. שם אפילו Auto DevOps הואמְאַפשֶׁר

לזהות, לבנות, לבדוק, לפרוס ולנטר את היישומים שלך באופן אוטומטי

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

מקור: www.habr.com