משימה 3: pull requests והמאשר

במשימה הזאת main מפסיק לקבל שינויים ישירות: שינוי מגיע אליו רק דרך pull request שעובר את ה‑checks שלו ויש לו אישור.

• המאשר הוא pr-reviewer, ה‑GitHub App מהקורס Git Collaboration: תחליף לחבר צוות בכיר.
  • בצוות אמיתי, אדם קורא כל pull request, ומאשר רק שינוי שלדעתו נכון.
  • ‏pr-reviewer לעולם לא קורא את הקוד: הוא מבקש שינויים פעם אחת, מחכה ל‑push, ואז מאשר, כדי שתתרגלו את הסבב של review.
• בזוג, גם הסטודנט השני מאשר: כל אחד מהאישורים מספיק ל‑merge, והאישור של הכותב עצמו לעולם לא נחשב.

תנו ל‑pr-reviewer גישה ל‑repository

‏GitHub App מותקן על החשבון שלכם, ועובד רק ב‑repositories שאתם נותנים לו: תנו לו את devops-project, ושום דבר אחר.

• בזוג, בעל ה‑repository עושה את זה: ה‑app מותקן על החשבון שלו.

הוסיפו את ההגדרות של ה‑reviewer

ה‑app קורא את ההוראות שלו מ‑.github/reviewer.yml, ורק מ‑main.

1. העתיקו את הקובץ מ‑team-rep ל‑repository שלכם:

   1$ mkdir -p .github
   2$ curl -fsSL -o .github/reviewer.yml https://raw.githubusercontent.com/YuvalShaul/team-rep/main/.github/reviewer.yml
   

   ההגדרות שלו, מתחת להערות שמסבירות כל אחת:

   1rounds: 1
   2merge: never
   

   • ‏rounds: 1: הוא מבקש שינויים פעם אחת, ומאשר ב‑push הבא.
   • ‏merge: never: כפתור ה‑merge נשאר שלכם.

2. עשו לו commit, ו‑push ל‑main:

   1$ git add .github/reviewer.yml
   2$ git commit -m "Configure pr-reviewer"
   3$ git push
   

• עשו את זה לפני שאתם מגינים על main: אחר כך הקובץ מגיע ל‑main רק דרך pull request, שעובר review של app בלי הגדרות.
• ‏pull request שעורך את הקובץ לא משנה כלום עד שהוא עובר merge: הכללים שלפיהם הוא נבחן מגיעים מ‑main.

הגנו על main

branch protection rule על main, מהסוג הקלאסי שהקורס Git Collaboration מגדיר בפרק Branch protection שלו. ה‑rulesets החדשים יותר של GitHub עושים את אותה עבודה במסך אחר; השתמשו ב‑rule הקלאסי, כי את הדף שלו אתם מכירים.

1. ‏Settings → Branches → Add branch protection rule, עם branch name pattern ‏main.
2. שלוש ההגדרות מהקורס:
   • Require a pull request before merging;
   • Require approvals: 1, מתחתיה;
   • Do not allow bypassing the above settings: בלעדיה אתם, הבעלים, admin, ו‑admins פטורים.
3. שתי הגדרות שהקורס לא היה צריך, כי לא היה לו pipeline:
   • Require status checks to pass before merging, ובחרו את ה‑jobs של pr.yml בשמם: ‏lint, ‏unit-tests, ‏integration-tests, ‏security, ‏image-build.
   • Require branches to be up to date before merging: כך ה‑checks של ה‑pull request רצו על הקוד שנוחת ב‑main, וה‑workflow של ה‑merge לא צריך לבדוק אותו שוב.
4. ‏Save changes.

• check מופיע ברשימה רק אחרי שהוא רץ פעם אחת: ה‑pull request שפתחתם במשימה 2 הוא מה ששם אותם שם.
• השם של check הוא השם של ה‑job שלו. job עם matrix מוסיף את הערך שלו, ‏unit-tests (3.13), וכל אחד מהם הוא check נפרד שצריך לדרוש.
• check נדרש שלעולם לא רץ חוסם את ה‑merge לתמיד. אם משימה מאוחרת יותר תיתן ל‑pr.yml פילטר paths:, ‏pull request שמשנה רק את ה‑README יחכה ל‑checks שלעולם לא מתחילים.
• force push ל‑main חסום על ידי ה‑rule כמו שהוא: הוא מאפשר אותו רק אם מסמנים את התיבה שמאפשרת.

עשו push ל‑main, וקראו את הדחייה

• ‏git push ישיר ל‑main נדחה. TODO: טקסט השגיאה.

פתחו pull request, וחכו למאשר

• ה‑checks רצים, וכפתור ה‑merge נשאר חסום.

• ‏pr-reviewer מבקש שינויים. ענו ב‑commit, ריק אם אין מה לשנות, ועשו לו push:

  1$ git commit --allow-empty -m "Answer the review"
  2$ git push
  

• ‏pr-reviewer מאשר, וכפתור ה‑merge עובד.

• עשו merge: ה‑workflow של ה‑merge רץ.

ה‑pipeline הריק שלם עכשיו: כל אירוע מריץ את ה‑jobs שלו, והשער מחזיק.