אוטומציה של גרסאות build בתגובה לאירועים של Pub/Sub

דור ראשון דור שני

טריגרים של Cloud Build Pub/Sub מאפשרים לכם להפעיל בנייה בתגובה לאירועים שפורסמו ב-Pub/Sub. Google Cloud אתם יכולים להשתמש במידע מאירוע Pub/Sub כדי להגדיר פרמטרים ל-build ולקבוע אם לבצע build בתגובה לאירוע. אפשר להגדיר טריגרים של Pub/Sub להאזנה לכל נושא Pub/Sub.

בדף הזה מוסבר איך ליצור טריגר Pub/Sub כדי להפוך את תהליך הבנייה לאוטומטי בתגובה לאירועים ב-Artifact Registry וב-Cloud Storage.

הערה: טריגרים של Pub/Sub הם סוג של טריגר שמשויך ל-Cloud Build. טריגרים של Pub/Sub שמשמשים בהקשרים נוספים ב- Google Cloud לא מתייחסים לטריגרים של Cloud Build Pub/Sub, אלא אם צוין אחרת במפורש.

מגבלות

הטריגרים של Cloud Build Pub/Sub לא נתמכים כשמשתמשים ב-VPC Service Controls.

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

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

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

  להפעלת ה-API

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

• כדי להשתמש בפקודות gcloud בדף הזה, צריך להתקין את Google Cloud CLI.

  הערה: אם התקנתם את ה-CLI של gcloud בעבר, צריך לוודא שפועלת אצלכם הגרסה העדכנית ביותר של gcloud components update.

יצירת טריגר לפיתוח גרסת Build שמגיב לאירועים ב-Artifact Registry

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

הערה: טריגרים של Pub/Sub לא יכולים לבצע build למאגרי GitHub Enterprise,‏ Bitbucket Data Center ו-Bitbucket Server באמצעות השילוב המובנה של Cloud Build. כדי לשכפל ולבנות מאגרים דרך מערכת חיצונית לניהול קוד מקור, אפשר לעיין במאמר יצירה וניהול של טריגרים של build כדי ללמוד איך לציין הגדרת build בשורה.

המסוף

כדי ליצור טריגר שמחכה לתג חדש שנדחף לתמונה קיימת ב-Artifact Registry באמצעות Google Cloud המסוף:

1. פותחים את הדף Triggers (מפעילים):

   פתיחת הדף Triggers

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

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

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

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

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

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

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

   • Event: בוחרים באפשרות Pub/Sub message בתור האירוע להפעלת הטריגר.

   • מינוי: בוחרים את נושא ה-Pub/Sub שרוצים להירשם אליו כמפעיל האירוע. בתפריט הנפתח מופיעים כל הנושאים הקיימים בפרויקט.

     • נושא ב-Pub/Sub: בוחרים את נושא gcr מהתפריט הנפתח או יוצרים את הנושא באופן ידני לפי ההוראות במאמר הגדרת התראות ב-Pub/Sub.
     הערה: אחרי שיוצרים את הטריגר, נוצר עבורכם באופן אוטומטי מינוי לטריגר. אפשר לראות את המינוי בדף המינויים ל-Pub/Sub.

   • מקור: בוחרים את המקור לבנייה כשמופעל טריגר Pub/Sub.

     הערה: האזור של מאגר הקוד חייב להיות זהה לאזור של הטריגר.

   • יצירת מאגר: בוחרים באפשרות דור שני.

   • מאגר: בוחרים את המאגר.

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

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

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

     • חובה, למעט בעלים ושותפי עריכה: כשבעלים או שותף עריכה של מאגר יוצרים או מעדכנים בקשת משיכה, הטריגר יפעיל אוטומטית את הבנייה. אם משתמש חיצוני יוזם את הפעולה, הבנייה תתבצע רק אחרי שבעלים או משתף פעולה יגיבו /gcbrun על בקשת המיזוג.

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

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

5. 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.

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

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

   מציינים את המשתנים והערכים הבאים:

   שם המשתנה	ערך המשתנה
   _IMAGE_TAG	$(body.message.data.tag)
   _ACTION	$(body.message.data.action)

   ‫body.message מתייחס ל-PubSubMessage שפורסם על ידי אפליקציות לשליחת הודעות ונצרך על ידי אפליקציות רשומות. דוגמאות נוספות למטען ייעודי (payload) של התראות Pub/Sub

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

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

   מומלץ להשתמש בסינון כשמגדירים טריגרים של Pub/Sub בנושאים עם כמה הודעות. אפשר להשתמש במסננים כדי לשלוט באופן מדויק בבנייה שמתבצעת בתגובה להודעות נכנסות של Pub/Sub. מידע על הסיכונים שקשורים להגדרת טריגר ללא מסננים זמין במאמר סיכונים שקשורים לטריגר ללא מסננים.

   בדוגמה הבאה, אנחנו רוצים שהטריגר יבצע build אם תג חדש מועבר לתמונה קיימת. אנחנו משתמשים באופרטורים של תנאי סינון כדי לבדוק אם המשתנה _IMAGE_TAG תואם לשם תג קיים, ואם המשתנה _ACTION תואם ל-INSERT כדי לחפש נתונים שנוספו לאחרונה.

   מגדירים את המסננים הבאים:

   • _IMAGE_TAG != ""
   • _ACTION == INSERT
   הערה: אפשר גם להגדיר תנאים מקוננים באמצעות האופרטורים הבוליאניים הבאים: && (וגם) ו-|| (או). אין תמיכה בסמל ! (לא).

   תחביר הסינון בטריגרים של Pub/Sub משתמש ב-Common Expression Language ‏ (CEL) להערכת ביטויים. מידע נוסף על CEL זמין במאגר cel-spec.

5. לוחצים על Create (יצירה) כדי ליצור את טריגר לפיתוח גרסת Build.

gcloud

כדי ליצור טריגר שמחכה לתג חדש שנדחף לתמונה קיימת ב-Artifact Registry באמצעות הפקודות gcloud:

1. פותחים חלון טרמינל.

2. מריצים את הפקודה gcloud כדי ליצור טריגר לפיתוח גרסת Build בפרויקט. בדוגמה הבאה, הטריגר מוגדר להגיב לבנייה עם תג שתואם ל-prod ולפעולה שתואמת ל-INSERT על סמך המטען הייעודי (payload) שצוין, כפי שמוגדר על ידי משתנה ההחלפה _IMAGE_TAG.

    gcloud builds triggers create pubsub \
      --region=REGION \
      --name=TRIGGER_NAME \
      --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
      --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
      --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
      --substitutions=\
        '_IMAGE_TAG_="$(body.message.data.tag)",' \
        '_ACTION="$(body.message.data.action)"' \
      --subscription-filter='_IMAGE_TAG != "" && _ACTION == "INSERT"' \
      --tag=TAG_NAME  # or --branch=BRANCH_NAME
   

כאשר:

• ‫REGION הוא האזור של הטריגר.
• ‫TRIGGER_NAME הוא השם של הטריגר.
• ‫PROJECT_ID הוא המזהה של פרויקט בענן.
• ‫CONNECTION_NAME הוא השם של חיבור המארח.
• ‫REPO_NAME הוא שם המאגר.
• ‫TOPIC_NAME הוא השם של נושא Pub/Sub שנרשמתם אליו.
• ‫BUILD_CONFIG הוא הנתיב לקובץ תצורת ה-build.
• ‫INLINE_BUILD_CONFIG הוא הנתיב לקובץ התצורה של ה-build בתוך הקובץ.
• ‫TAG_NAME הוא שם התג אם רוצים להגדיר את הטריגר כך שיתבסס על תג.
• ‫BRANCH_NAME הוא שם הענף אם רוצים להגדיר את הטריגר כך שיבנה על ענף.

יצירת טריגר לפיתוח גרסת Build שמגיב לאירועים ב-Cloud Storage

אתם יכולים ליצור טריגר Pub/Sub שמגיב לאירועים ב-Cloud Storage, כמו כשקובץ בינארי חדש נדחף לקטגוריית אחסון קיימת. בקטע הזה מוסבר איך ליצור טריגר Pub/Sub שמגיב באמצעות build כשפורסים קובץ בינארי חדש לקטגוריה שהועלתה. אם אתם לא מכירים את Cloud Storage, תוכלו להיעזר במדריכים למתחילים.

המסוף

כדי ליצור טריגר שמקשיב לאירועים ב-Cloud Storage באמצעות Google Cloud המסוף:

1. פותחים את הדף Triggers (מפעילים):

   פתיחת הדף Triggers

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

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

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

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

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

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

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

   • Event: בוחרים באפשרות Pub/Sub message בתור האירוע להפעלת הטריגר.

   • Subscription: בוחרים את נושא ה-Pub/Sub שאליו רוצים להירשם כמנוי בתור אירוע מפעיל. בתפריט הנפתח מופיעים כל הנושאים הקיימים בפרויקט.

     • נושא Pub/Sub: בוחרים את נושא gcs מהתפריט הנפתח או יוצרים את הנושא באופן ידני באמצעות ההוראות במאמר הגדרת התראות Pub/Sub ל-Cloud Storage.
     הערה: אחרי שיוצרים את הטריגר, נוצר עבורכם באופן אוטומטי מינוי לטריגר. אפשר לראות את המינוי בדף המינויים ל-Pub/Sub.

   • מקור: בוחרים את המקור לבנייה כשמופעל טריגר Pub/Sub.

     הערה: האזור של מאגר המידע צריך להיות זהה לאזור של הטריגר.

   • יצירת מאגר: בוחרים באפשרות דור שני.

   • מאגר: בוחרים מאגר.

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

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

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

     • חובה, למעט בעלים ושותפי עריכה: כשבעלים או שותף עריכה של מאגר יוצרים או מעדכנים בקשת משיכה, הטריגר יפעיל אוטומטית את הבנייה. אם משתמש חיצוני יוזם את הפעולה, הבנייה תתבצע רק אחרי שבעלים או משתף פעולה יגיבו /gcbrun על בקשת המיזוג.

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

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

5. 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.

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

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

   מציינים את המשתנים והערכים הבאים:

   שם המשתנה	ערך המשתנה
   _EVENT_TYPE	$(body.message.attributes.eventType)
   _BUCKET_ID	$(body.message.attributes.bucketId)
   _OBJECT_ID	$(body.message.attributes.objectId)

   ‫body.message מתייחס ל-PubSubMessage שפורסם על ידי אפליקציות לשליחת הודעות ונצרך על ידי אפליקציות רשומות. דוגמאות נוספות למטען ייעודי (payload) של התראות Pub/Sub

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

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

   מומלץ להשתמש בסינון כשמגדירים טריגרים של Pub/Sub בנושאים עם כמה הודעות. אפשר להשתמש במסננים כדי לשלוט באופן מדויק בבנייה שמתבצעת בתגובה להודעות נכנסות של Pub/Sub. מידע על הסיכונים שקשורים להגדרת טריגר ללא מסננים זמין במאמר סיכונים שקשורים לטריגר לא מסונן.

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

   מגדירים את המסננים הבאים:

   • _EVENT_TYPE == OBJECT_FINALIZE
   • _OBJECT_ID משחקים ^<object-id>$
   • _BUCKET_ID משחקים ^<bucket-id>$

5. לוחצים על Create (יצירה) כדי ליצור את טריגר לפיתוח גרסת Build.
.

gcloud

כדי ליצור טריגר לפיתוח גרסת Build שמקשיב לאירועי build עם סוג אירוע ספציפי ב-Cloud Storage:

1. פותחים חלון טרמינל.

2. מריצים את הפקודה gcloud כדי ליצור טריגר לפיתוח גרסת Build בפרויקט. בדוגמה הבאה, הטריגר מוגדר להגיב לבנייה עם אירוע Cloud Storage שמשויך לקובץ בינארי חדש שנשלח לקטגוריית אחסון קיימת:

    gcloud builds triggers create pubsub \
      --region=REGION \
      --name=TRIGGER_NAME \
      --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
      --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
      --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
      --substitutions=\
        '_EVENT_TYPE="$(body.message.attributes.eventType)",' \
        '_BUCKET_ID="$(body.message.attributes.bucketId)",' \
        '_OBJECT_ID="$(body.message.attributes.objectId)"' \
      --subscription-filter='_EVENT_TYPE == "OBJECT_FINALIZE" && _OBJECT_ID.matches("<object-id>") && _BUCKET_ID.matches("<bucket-id>")' \
      --tag=TAG_NAME  # or --branch=BRANCH_NAME
   

כאשר:

• ‫REGION הוא האזור של הטריגר.
• ‫TRIGGER_NAME הוא השם של הטריגר.
• ‫PROJECT_ID הוא המזהה של פרויקט בענן.
• ‫CONNECTION_NAME הוא השם של חיבור המארח.
• ‫REPO_NAME הוא שם המאגר.
• ‫TOPIC_NAME הוא השם של נושא Pub/Sub שנרשמתם אליו.
• ‫BUILD_CONFIG הוא הנתיב לקובץ תצורת ה-build.
• ‫INLINE_BUILD_CONFIG הוא הנתיב לקובץ התצורה של ה-build בתוך הקובץ.
• ‫TAG_NAME הוא שם התג אם רוצים להגדיר את הטריגר כך שיתבסס על תג.
• ‫BRANCH_NAME הוא שם הענף אם רוצים להגדיר את הטריגר כך שיבנה על ענף.

סיכונים שקשורים לטריגר לא מסונן

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

• מפנה לנושא gcr.
• יצירת תמונה או תג ב-gcr.
• מצביע על נושא gcs של אובייקט ספציפי בקטגוריה ומשנה את האובייקט הזה.

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

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

• איך מתחילים לבצע build באופן ידני באמצעות פקודות gcloud או Cloud Build API.
• איך יוצרים ומנהלים טריגרים
• איך צופים בתוצאות של בניית האפליקציה
• איך פותרים בעיות שקשורות לבנייה