יצירת מאגרים מ-GitHub Enterprise

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

באמצעות Cloud Build אפשר ליצור טריגרים לבנייה ממאגרים שמתארחים ב-GitHub Enterprise. אתם יכולים להריץ בנייה בתגובה לאירועים כמו שליחת קומיטים או בקשות מיזוג שמשויכים למאגר GitHub Enterprise שלכם.

בדף הזה מוסבר איך להפעיל טריגרים של בנייה עבור מופע של GitHub Enterprise. מידע נוסף זמין במאמרים בנושא טריגרים של Cloud Build ומאגרי Cloud Build.

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

פועלים לפי ההוראות להתחברות למארח GitHub Enterprise.

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

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

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

  הפעלת ממשקי ה-API

כדי ליצור טריגר למאגר GitHub Enterprise, צריך ליצור חיבור בין Google Cloud לבין המאגר. כדי ליצור חיבור דרך אפליקציית GitHub Enterprise ב- Google Cloud, אפשר לעיין במאמר חיבור למאגר GitHub Enterprise.

יצירת טריגר של GitHub Enterprise

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

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

מסוף Google Cloud

כדי ליצור טריגרים של GitHub Enterprise באמצעות המסוף Google Cloud , מבצעים את הפעולות הבאות:

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

   פתיחת הדף Triggers

2. בוחרים את Google Cloud הפרויקט ולוחצים על פתיחה.

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

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

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

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

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

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

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

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

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

     • בקשת משיכה: מגדירים את הטריגר להתחלת בנייה בהתחייבויות לבקשת משיכה.

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

   • מקור: הגדרת מידע על מאגר GitHub Enterprise:

     • שירות מאגר: בוחרים באפשרות Cloud Build.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • Build logs (יומני בנייה) (אופציונלי): מסמנים את התיבה כדי לשלוח יומני בנייה ל-GitHub. במאמר הצגת יומני בנייה מוסבר איך לצפות ביומני בנייה.

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

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

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

כדי ליצור טריגרים של GitHub באמצעות פקודות gcloud, אפשר לעיין בgcloudפקודות ליצירת טריגר לפיתוח גרסת Build.

‫CLI של gcloud

כדי ליצור טריגרים של GitHub Enterprise באמצעות פקודות gcloud, מריצים את הפקודה הבאה:

    gcloud builds triggers create github \
      --name=TRIGGER_NAME \
      --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
      --branch-pattern=BRANCH_PATTERN # or --tag-pattern=TAG_PATTERN \
      --build-config=BUILD_CONFIG_FILE \
      --region=REGION \
      --service-account=SERVICE-ACCOUNT

כאשר:

• ‫TRIGGER_NAME הוא השם של הטריגר.
• ‫PROJECT_ID הוא מזהה הפרויקט. Google Cloud
• ‫REGION הוא האזור של הטריגר.
• ‫CONNECTION_NAME הוא השם של החיבור ל-GitHub Enterprise.
• ‫REPO_NAME הוא שם המאגר
• ‫BRANCH_PATTERN הוא שם הענף במאגר שבו רוצים להפעיל את ה-build.
• ‫TAG_PATTERN הוא שם התג במאגר שמשמש להפעלת ה-build.
• ‫BUILD_CONFIG_FILE הוא הנתיב לקובץ התצורה של ה-build.
• ‫SERVICE-ACCOUNT הוא חשבון השירות שבו יש להשתמש לפעולות של הפעלה ובנייה.

API

כדי ליצור טריגר של GitHub Enterprise באמצעות ה-API, משתמשים בתבנית ה-JSON הבאה:

{
    "filename": "cloudbuild.yaml",
    "name": "curl-trigger",
    "description": "curl trigger",
    "repository_event_config": {
      "repository": "REPO_NAME",
      "repository_type": "GITHUB_ENTERPRISE",
      // Field filter must be only one of the following:
      "pullRequest": "PULL_REQUEST_FILTER",
      "push": "PUSH_FILTER"
    }
}

כאשר:

• ‫REPO_NAME הוא השם של חיבור המאגר שהגדרתם ב-Cloud Build.
• ‫PULL_REQUEST_FILTER הוא מופע של PullRequestFilter, שמגדיר את המסנן שמאפשר ל-Cloud Build להפעיל בנייה כשמתבצעת בקשת משיכה תואמת ב-GitHub Enterprise.
• ‫PUSH_FILTER הוא מופע של PushFilter, שמגדיר את המסנן שמאפשר ל-Cloud Build להפעיל build כשמתבצעת פעולת push תואמת ב-GitHub Enterprise.

מזינים את הפקודה curl הבאה בטרמינל:

  curl -X POST -H "Authorization: Bearer "$(gcloud auth print-access-token) -H "Content-Type: application/json; charset=utf-8" -H "x-goog-user-project: PROJECT_NUMBER" https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/triggers -d @trigger.json

כאשר:

• ‫PROJECT_NUMBER הוא מספר הפרויקט שלכם ב- Google Cloud .
• ‫PROJECT_ID הוא מזהה הפרויקט. Google Cloud

שיתוף נתונים

הנתונים שנשלחים אל GitHub Enterprise מ-Cloud Build עוזרים לכם לזהות טריגרים לפי שם ולראות את תוצאות הבנייה ב-GitHub Enterprise.

הנתונים הבאים משותפים כרגע בין Cloud Build לבין GitHub Enterprise:

• מזהה פרויקט ב-Cloud
• שם הטריגר
• יומני Build

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

אם יצרתם טריגרים לפני אוגוסט 2020, יכול להיות ששיתוף הנתונים לא מופעל בפרויקט שלכם. כדי להפעיל שיתוף נתונים לכל הטריגרים של GitHub Enterprise בפרויקט, לוחצים על Enable בכרטיסייה Cloud Build Data sharing.

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

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

הערה: אי אפשר לבטל את שיתוף הנתונים בפרויקט.

השלבים הבאים

• איך יוצרים ומנהלים טריגרים
• כאן מוסבר איך ליצור מאגרים מ-GitHub Enterprise ברשת פרטית.
• איך מבצעים פריסות כחולות-ירוקות ב-Compute Engine