4 תבניות GitHub Actions עבור Monorepo ETL
הרצת שלושה אתרים מתוך monorepo אחד יוצרת בעיות. אתם מתמודדים עם שלושה תהליכי ETL נפרדים, שלושה בנייה מחדש (rebuilds) של תוכן, ושלושה צינורות פריסה (deployment pipelines). אם לא תתאמו ביניהם, הם יתנגשו.
ביליתי שישה שבועות בבדיקת לוחות זמנים כדי לייצב את המבנה הזה. להלן ארבע התבניות שבהן אני משתמש.
- שימוש בהסטת זמן (Time Offsets) עבור משימות Cron
הרצת כל משימות ה-ETL באותו זמן גורמת לכשלים. המשימות מתחרות על מגבלות קצב ה-API (rate limits). כאשר HuggingFace או GitHub מחזירים שגיאת 429, ההרצה נכשלת.
אני משתמש בהסטות של 30 דקות כדי למנוע זאת.
- משימה אחת מתחילה ב-02:00
- משימה שנייה מתחילה ב-02:30
- משימה שלישית מתחילה ב-03:00
שלושים דקות הן זמן מספיק כדי לסיים משיכת נתונים (pull) כבדה לפני שהמשימה הבאה מתחילה. זה שומר על הלוגים (logs) נקיים ומונע התנגשויות API.
- שימוש בדגלי דילוג (Skip Flags) כדי לעצור בנייה מחדש מיותרת
כל משימת ETL מסתיימת בפריסה ב-Vercel. בעיה מתעוררת כאשר commits של מאמרים מפעילים גם הם בנייה מחדש. ללא תוכנית, כל עדכון מאמר מאלץ את שלושת האתרים לבנות את עצמם מחדש. זה מבזבז דקות בנייה (build minutes).
אני משתמש בתגית [skip publish-articles] בהודעות ה-commit של ה-ETL.
הוספתי שלב ב-workflow שלי שבודק את הדגל הזה. אם התגית קיימת, ה-workflow מדלג על שלב הבנייה והפריסה. זה שומר על צינורות ה-ETL נפרדים מצינורות המאמרים.
- שימוש במסנני נתיבים (Path Filters) כדי להתמקד באתרים ספציפיים
אתם לא רוצים שעדכון של אתר אחד יפעיל שלוש פריסות. אני מגדיר את ה-workflow של כל אתר כך שיעקוב רק אחרי התיקייה שלו ואחרי תיקיית החבילות המשותפות (shared packages).
לוגיקת דוגמה:
- אתר כלי ה-AI עוקב רק אחרי
apps/ai-tools/ - אתר ה-OSS עוקב רק אחרי
apps/oss-alternatives/
אם תשנו קוד בתיקייה המשותפת, כל האתרים ייבנו מחדש. אני מקבל את הפשרה הזו מכיוון ששינויים בקוד משותף הם נדירים.
- הוספת הפעלה ידנית (Manual Dispatch) לצורך שליטה
ה-Cron מטפל בשגרה היומית. ההפעלה הידנית מטפלת בכל השאר. אני משתמש ב-workflow_dispatch כדי שאוכל:
- להריץ מחדש משימת ETL שנכשלה
- לאלץ רענון לאחר הוספת נתונים
- להריץ dry run כדי לבדוק נתונים מבלי לכתוב לבסיס הנתונים
ממשק המשתמש של GitHub מציג תפריט נפתח עבור הבחירות הללו. זה מונע שגיאות הקלדה והופך את הדיבאגינג (debugging) לקל.
Summary
התבניות הללו אינן מורכבות. הן מפורשות. אני שומר קובץ markdown פשוט במאגר (repository) שלי כדי לתעד את הכללים הללו. זה מבטיח שלא אשבור את המערכת כשאוסיף workflows חדשים.