אוטומציה של גרסאות build באמצעות Cloud Build

בקטע הזה נסביר איך ליצור אוטומציה של בנייה באמצעות Cloud Build ו-Cloud Source Repositories.

אתם יכולים להגדיר את Cloud Build כך שיבנה באופן אוטומטי תמונה חדשה בכל פעם שמשתמש מעביר שינוי לקבצים שמאוחסנים ב-Cloud Source Repositories. אירועים שמפעילים גרסאות build אוטומטיות נקראים טריגרים של build. הטריגרים האלה יכולים לעזור לכם לוודא שתמונות הקונטיינר שלכם יישארו עדכניות. אפשר גם להשתמש בהם כדי ליצור ולבדוק ענפים של תכונות.

טריגרים של build יכולים לבצע build על סמך קובץ Dockerfile או קובץ build config.

שימוש בקובץ Dockerfile

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

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

שימוש בקובץ תצורת build

כדי להשתמש בקובץ תצורת build להגדרת ה-build, צריך לציין את המיקום של קובץ תצורת build.

אחרי שתגדירו את המיקום, יוצג סיכום של הטריגר.

לפני שמתחילים

• מפעילים את Cloud Build API.

  הפעלת Cloud Build API

• מוודאים שיש קוד מקור ב-Cloud Source Repositories.

• מוודאים שיש לכם Dockerfile או קובץ הגדרות build.

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

מידע נוסף

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

• אם אתם משתמשים בספק אחר של Git מארח, כמו GitHub או Bitbucket, ועדיין צריכים לשכפל את המאגר ל-Cloud Source Repositories, אתם צריכים לקבל את ההרשאה cloudbuilds.builds.create לפרויקט Google Cloudשבו אתם עובדים. בדרך כלל מקבלים את ההרשאה הזו דרך התפקיד cloudbuild.builds.editor.

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

  אחרי שמגדירים את המאגר החיצוני, Cloud Source Repositories יוצר העתק של המאגר.

• מידע על המכסות והמגבלות של Cloud Build זמין במאמר מכסות ומגבלות במסמכי התיעוד של Cloud Build.

יצירת טריגר לפיתוח גרסת Build

המסוף

1. פותחים את הדף Triggers במסוף Google Cloud .

   פתיחת הדף Triggers

2. בוחרים את הפרויקט מהתפריט הנפתח לבחירת פרויקט בחלק העליון של הדף.

3. לוחצים על פתיחה.

4. לוחצים על Create trigger (יצירת ביטוי להפעלה).

5. מזינים את הגדרות הטריגר הבאות:

   • שם: מזינים שם לטריגר.

   • תיאור (אופציונלי): מזינים תיאור להפעלה.

   • אירוע: בוחרים את האירוע במאגר שיפעיל את הטריגר.

     • Push to a branch: מגדירים את הטריגר להתחלת בנייה של קומיטים בענף מסוים.

     • Push new tag (העלאת תג חדש): מגדירים את הטריגר להתחלת בנייה בהתחייבויות שמכילות תג מסוים.

       הערה: בין אם מדובר ב-commits של ענפים או ב-commits של תגים, הפעלת ה-build מתבצעת רק בפעולות push למקור המרוחק – ולא בשינויים מקומיים, בבדיקות לפני שליחה או בבקשות משיכה.

   • מקור: בוחרים את המאגר ואת הענף או התג המתאימים למעקב אחרי אירועים.

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

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

     • Branch או Tag: מציינים ביטוי רגולרי עם ערך הענף או התג להתאמה. אי אפשר להשתמש בקו נטוי (/) בתגים. מידע נוסף על תחביר מקובל של ביטויים רגולריים זמין במאמר בנושא תחביר RE2.

   • Configuration (תצורה): בוחרים את קובץ תצורת ה-build שנמצא במאגר המרוחק או יוצרים קובץ תצורת build מוטבע לשימוש ב-build.

     • סוג: בוחרים את סוג ההגדרה שרוצים להשתמש בה ב-build.
       • קובץ תצורה של Cloud Build‏ (yaml או json): משתמשים בקובץ תצורת build להגדרה.
       • ‫Dockerfile: משתמשים ב-Dockerfile להגדרה.
       • ‫Buildpacks: משתמשים ב-buildpacks להגדרה.

     • מיקום: מציינים את המיקום של ההגדרה.

       • מאגר: אם קובץ ההגדרות נמצא במאגר המרוחק, צריך לציין את המיקום של קובץ הגדרות ה-Build, של הספרייה Dockerfile או של ספריית ה-buildpacks. אם סוג ההגדרה של ה-build הוא Dockerfile או buildpack, תצטרכו לספק שם לקובץ האימג' שיתקבל, ואם רוצים, גם הגדרת זמן קצוב לתהליך ה-build. אחרי שתספקו את שם התמונה של Dockerfile או של buildpack, תוכלו לראות תצוגה מקדימה של הפקודה docker build או pack שה-build יבצע.
       • משתני סביבה של Buildpack (אופציונלי): אם בחרתם באפשרות buildpacks כסוג ההגדרה, לוחצים על Add pack environment variable (הוספת משתנה סביבה של pack) כדי לציין את משתני הסביבה והערכים של ה-buildpack. מידע נוסף על משתני סביבה של buildpack זמין במאמר משתני סביבה.

       • בתוך השורה: אם בחרתם באפשרות קובץ תצורת build ב-Cloud Build (yaml או json), תוכלו לציין את תצורת ה-build בתוך השורה. לוחצים על Open Editor (פתיחת עורך) כדי לכתוב את קובץ הגדרות ה-build במסוףGoogle Cloud באמצעות תחביר YAML או JSON. לוחצים על סיום כדי לשמור את הגדרות ה-build.

         הערה: אין תמיכה בתצורת build מוטבעת ב-Dockerfile או ב-buildpacks.

   • חשבון שירות: בוחרים את חשבון השירות שבו רוצים להשתמש כשמפעילים את הטריגר. אם לא בוחרים חשבון שירות, נעשה שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build.

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

6. לוחצים על יצירה כדי לשמור את טריגר לפיתוח גרסת Build.

gcloud

מריצים את הפקודה הבאה:

    gcloud beta builds triggers create cloud-source-repositories \
    --repo=REPO_NAME \
    --branch-pattern=BRANCH_PATTERN \ # or --tag-pattern=TAG_PATTERN
    --build-config=BUILD_CONFIG_FILE \
    --service-account=SERVICE_ACCOUNT \
    --require-approval

כאשר:

• ‫REPO_NAME הוא שם המאגר.
• ‫BRANCH_PATTERN הוא שם הענף במאגר שבו רוצים להפעיל את ה-build.
• ‫TAG_PATTERN הוא שם התג במאגר שמשמש להפעלת ה-build.
• ‫BUILD_CONFIG_FILE הוא הנתיב לקובץ התצורה של ה-build.
• ‫SERVICE_ACCOUNT (תצוגה מקדימה) היא כתובת האימייל שמשויכת לחשבון השירות שלכם. אם לא כוללים את הדגל הזה, המערכת משתמשת בחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build.

הערה: רק חשבון השירות שצוין בפקודה gcloud beta build triggers create משמש לבנייה של טריגרים. טריגרים של build מתעלמים מחשבון השירות שצוין בקובץ התצורה של ה-build.

• [אופציונלי] --require-approval הוא הדגל שצריך לכלול כדי להגדיר את הטריגר כך שיידרש אישור.

רשימה מלאה של הדגלים מופיעה במאמר gcloud reference for how to create triggers for Cloud Source Repositories.

אחרי שמריצים את הפקודה gcloud כדי ליצור טריגר באמצעות Cloud Source Repositories, אמור להופיע פלט שדומה לזה שמופיע בדוגמה הבאה:

  NAME         CREATE_TIME                STATUS
  trigger-001  2019-10-30T20:45:03+00:00

הערה: שם הטריגר נוצר אוטומטית. אפשר לשנות את השם של הטריגר דרך Google Cloud הקונסולה.

הצגת טריגרים של גרסאות Build

כדי לראות את הטריגרים במסוף Google Cloud , פותחים את הדף Triggers ב-Cloud Build.

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

דילוג על טריגר לפיתוח גרסת Build

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

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

לדוגמה:

Author: A User <[e-mail]>
Date:   Tue Apr 3 12:03:35 2018 -0700

Fixed customer affecting issue. [skip ci]

אם רוצים להריץ build על הקומיט הזה מאוחר יותר, לוחצים על הלחצן Run trigger.

ביטול שיבוטים רדודים

כדי לבנות את המקור במאגר Git, ‏ Cloud Source Repositories מבצע עותק מקוצר של המאגר. כש-Cloud Source Repositories מבצע עותק מקוצר, הוא מוציא מסביבת העבודה רק את השמירה היחידה שהפעילה את ה-build, ואז הוא בונה מהמקור הזה. ‫Cloud Source Repositories לא בודק ענפים אחרים או היסטוריה. הפעולה הזו מתבצעת כדי לשפר את היעילות. הבנייה לא מתעכבת בזמן ש-Cloud Source Repositories מאחזר את כל המאגר ואת ההיסטוריה רק כדי לבנות מתוך קומיט יחיד.

כדי לכלול ב-build חלק גדול יותר מההיסטוריה של מאגר הקוד, מוסיפים שלב build לקובץ התצורה של ה-build כדי לבטל את השכפול הרדוד. לדוגמה:

steps:
- name: gcr.io/cloud-builders/git
  args: ['fetch', '--unshallow']
...

מידע נוסף על git fetch זמין במאמר הפניה ל-Git. הוראות לכתיבת קובץ תצורת build מופיעות במאמר סקירה כללית על תצורת build.

המאמרים הבאים

• איך מתחילים לבנות באופן ידני ב-Cloud Build
• מידע נוסף על יצירה, בדיקה ופריסה של ארטיפקטים