GitHub

מחברים את הריפו פעם אחת, והאפליקציה נבנית בלי המחשב שלך: ‏Ploa בודקת כל pull request מול הכללים של החנויות, בונה ב-⁠GitHub Actions שלך ומעלה את הבנייה ל-⁠TestFlight ולבדיקה של Google Play, עם קישור התקנה ב-⁠pull request. שום מפתח לא נכנס לריפו.

מה לבקש מהסוכן

הכלים שמאחורי הבקשות האלה: כל כלי ה-⁠MCP › GitHub.

מי עושה מה

חיבור וקישור

1. מתקינים את אפליקציית GitHub של Ploa

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

2. מקשרים את האפליקציה

   הריפו, התיקייה של האפליקציה וענף השחרור. הסוכן קורא אותם מהעותק שלך ומבקש; אתה מאשר ב-⁠ploa.dev. הקישור קובע איזה ריפו יקבל בהרצות שלו את החתימה של האפליקציה, ולכן אתה מאשר אותו בעצמך (קישור של סוכן אוטונומי נעשה מיד).

3. מוסיפים את ה-⁠workflow של Ploa

   ‏Ploa עושה commit לקובץ ה-⁠workflow שלה בענף השחרור (או פותחת pull request כשהענף מוגן), ברגע שלאפליקציית ה-⁠GitHub יש את הרשאת Workflows. עד אז מוסיפים אותו מהכרטיס, או שהסוכן מוסיף אותו בעותק שלך ופותח pull request.

פלטפורמה שהבנייה שלה נמצאת בתיקייה אחרת באותו ריפו (אפליקציית Mac ב-⁠mac/, למשל) מקבלת את התיקייה הזו בכרטיס.

בדיקות על pull requests

כל pull request נבדק מול מה שהחנויות דוחות, והממצאים מופיעים על השורות שהם נוגעים בהן. זו אותה בדיקה מקדימה כמו ploa preflight, שרצה כ-⁠check ב-⁠GitHub, לכל אפליקציה שה-⁠pull request משנה את התיקייה שלה. אפשר להפוך אותה לבדיקה חובה ב-⁠branch protection. ‏pull request מ-⁠fork עובר עם הודעה, כי ההרצה שלו לא יכולה להזדהות.

בניות ב-⁠GitHub Actions

• מתחילים בנייה מכפתור הבנייה בלוח הבקרה, מהסוכן שלך, או עם תווית על pull request: ploa:android, ploa:ios או ploa:all בונה את הקומיט האחרון של ה-⁠pull request (את התוויות מפעילים בכרטיס). סוכן שמתבקש לבנות בכל מקום בונה ב-⁠GitHub ברגע שהפלטפורמה מוכנה שם; סוכנים ברשת תמיד בונים ב-⁠GitHub.
• אנדרואיד נבנה על מכונות ה-⁠Linux של GitHub.
• ‏iOS נבנה על ה-⁠Mac שלך, שרשום כ-⁠self-hosted runner (ploa runner add), או על מחשבי ה-⁠Mac של GitHub אם זה מותר לאפליקציה (בהמשך). על מחשבי ה-⁠Mac של GitHub, זהות החתימה עוברת למכונה של GitHub רק לאותה בנייה, ב-⁠keychain שנמחק בסוף; המפתח של App Store Connect אף פעם לא יוצא מ-⁠Ploa.
• בלי סודות בריפו. ה-⁠workflow של Ploa מזדהה בתור ההרצה עצמה (ה-⁠OIDC של GitHub), כך שאין טוקן או מפתח ב-⁠secrets של הריפו.
• קבצים שלא נמצאים ב-⁠git, כמו .env או google-services.json: ‏Ploa אומרת אילו מהם בנייה תפספס. מוסיפים אותם בכרטיס, או שולחים אותם מהעותק שלך עם ploa files push (או דרך הסוכן), ואתה מאשר אותם פעם אחת. עד 20 קבצים, ‏256 KB כל אחד, אף פעם לא מפתח חנות או מפתח חתימה. בנייה כותבת אותם לפני שהיא מתחילה ומוחקת אותם בסוף, והערכים של .env מוסתרים בלוג.
• התקנה מה-⁠pull request. כשהבנייה מגיעה לבודקים, ה-⁠pull request מקבל תגובה אחת, שמתעדכנת בכל בנייה חדשה: ל-⁠iOS בניית ה-⁠TestFlight, עם הקישור הציבורי וקוד ה-⁠QR שלו כשיש לאפליקציה כזה; לאנדרואיד קישור internal app sharing של Play וקוד ה-⁠QR שלו. בודק מפעיל internal app sharing פעם אחת בחנות Play, והאפליקציה צריכה קודם גרסה במסלול כלשהו.

ploa runner add --repo owner/name   # this Mac as the repository's iOS runner
ploa runner status
ploa runner remove --repo owner/name
ploa files                          # build files: in git, kept by Ploa, or missing
ploa files push                     # send the missing ones, for your approval

כמה עולות בניות ב-⁠GitHub

מ-⁠Ploa, כלום. ‏GitHub סופרת את הדקות בחשבון ה-⁠GitHub שלך: בחינם בריפו ציבורי; בריפו פרטי הן יורדות מהדקות החינמיות החודשיות של התוכנית שלך, כשדקת Linux נספרת כאחת ודקת Mac כעשר (בנייה של iOS על מחשבי ה-⁠Mac של GitHub משתמשת בערך ב-⁠150 עד 200). בניות על ה-⁠Mac שלך כ-⁠runner לא משתמשות בדקות בכלל. הסוכן אומר לך לפני בנייה של iOS על מחשבי ה-⁠Mac של GitHub.

הגדרות ה-⁠GitHub של האפליקציה

המתגים בכרטיס ה-⁠GitHub של האפליקציה. הסוכן יכול לבקש לשנות אותם, ואת השינוי אתה מאשר ב-⁠ploa.dev.

דף החנות מהריפו

קובץ טקסט אחד לכל חנות, שפה ושדה: store/apple/<language>/<field>.txt (‏name, ‏subtitle, ‏promotionalText, ‏description, ‏keywords, ‏whatsNew, ‏supportUrl, ‏marketingUrl, ‏privacyPolicyUrl) ו-⁠store/google/<language>/<field>.txt (‏title, ‏shortDescription, ‏fullDescription, ‏video). ‏push לענף השחרור שמוסיף או משנה קובץ כזה הופך אותו לטיוטה, שנבדקת מול המגבלות של החנות, ותגובה על הקומיט אומרת מה הפך לטיוטה ומה נדחה ולמה. בכיוון אחד בלבד: ‏Ploa אף פעם לא כותבת ל-⁠store/, קובץ שנמחק לא משנה כלום, ואת הפרסום אתה עדיין עושה בעצמך. ייצוא בכרטיס פותח pull request עם דף החנות של היום כקבצים, כדי להתחיל ממנו. צילומי מסך לא נכללים. ראה דף החנות.

‏Issues מהחנויות

• דחיות של App Review: ‏issue עם מה ש-⁠Apple אמרה ומה לתקן, שנסגר כשהגרסה מאושרת.
• ביקורות עם מעט כוכבים: לכל היותר issue אחד ביום לכל חנות, עם הביקורות החדשות של כוכב אחד ושניים.
• קריסות: ‏issue כל עוד שיעור הקריסות או ה-⁠ANR ב-⁠Google Play מעל סף ההתנהגות הגרועה של Play, שנסגר כשהוא חוזר מתחת.
• משוב מ-⁠TestFlight: ההערות של הבודקים, המכשיר והבנייה, והלוג של קריסה.

סוכן שעובד על issues (‏Claude Code's GitHub Action, סוכן הקוד של GitHub) יכול לקחת אותם משם. כל מקור מתחיל מהרגע שמפעילים אותו.

סוכנים ב-⁠GitHub Actions

סוכן שרץ ב-⁠workflow מריץ ploa mcp על ה-⁠runner, ומזדהה בתור ההרצה, לכל היותר ברמת טיוטה. האישורים נשארים אצלך.

מה Ploa עושה בריפו שלך

היא קוראת את הריפוזיטורים שבחרת. היא משנה משהו רק אחרי שמפעילים את זה, ואז רק דרך pull request, ‏check, ‏issue, תגובה או תג. היא מריצה רק את ה-⁠workflow שלה ואף פעם לא דוחפת לענפים שלך. ב-⁠push היא בודקת את השמות של הקבצים שהשתנו (אף פעם לא את התוכן) ומחפשת מפתח חנות, תעודה או keystore, ומתריעה לבעלים של סביבת העבודה אם נדחף כזה; הבדיקה המקדימה בודקת את קבצי הפרויקט גם לפני בנייה. אפשר להסיר את אפליקציית ה-⁠GitHub של Ploa בכל רגע.

בלוח הבקרה

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