4 รูปแบบ GitHub Actions สำหรับ Monorepo ETL
การรันเว็บไซต์สามแห่งจาก monorepo เดียวกันสร้างปัญหา คุณต้องเผชิญกับงาน ETL สามงาน, การ rebuild เนื้อหาสามครั้ง และ deployment pipelines สามชุด หากคุณไม่ประสานงานกัน พวกมันจะชนกัน
ผมใช้เวลาหกสัปดาห์ในการทดสอบตารางเวลาเพื่อทำให้การตั้งค่านี้เสถียร นี่คือสี่รูปแบบที่ผมใช้
- ใช้ Time Offsets สำหรับ Cron Jobs
การรันงาน ETL ทั้งหมดพร้อมกันทำให้เกิดความล้มเหลว งานต่างๆ จะแย่งชิง API rate limits เมื่อ HuggingFace หรือ GitHub ส่ง error 429 กลับมา การรันจะล้มเหลว
ผมใช้การตั้งเวลาเหลื่อมกัน (offsets) 30 นาทีเพื่อป้องกันปัญหานี้
- งานแรกเริ่มที่ 02:00
- งานที่สองเริ่มที่ 02:30
- งานที่สามเริ่มที่ 03:00
เวลา 30 นาทีนั้นเพียงพอที่จะดึงข้อมูลหนักๆ ให้เสร็จก่อนที่งานถัดไปจะเริ่ม วิธีนี้ช่วยให้ log ของคุณสะอาดและป้องกันการชนกันของ API
- ใช้ Skip Flags เพื่อหยุดการ Rebuild ที่ไม่จำเป็น
งาน ETL ทุกงานจะจบลงด้วยการ deploy บน Vercel ปัญหาจะเกิดขึ้นเมื่อการ commit บทความไปกระตุ้นให้เกิดการ rebuild ด้วย หากไม่มีแผน การอัปเดตบทความทุกครั้งจะบังคับให้ทั้งสามไซต์ต้อง rebuild ซึ่งเป็นการสิ้นเปลือง build minutes
ผมใช้ tag [skip publish-articles] ในข้อความ commit ของ ETL
ผมเพิ่มขั้นตอนใน workflow เพื่อตรวจสอบ flag นี้ หากมี tag นี้อยู่ workflow จะข้ามขั้นตอนการ build และ deploy วิธีนี้ช่วยแยก ETL pipelines ออกจาก article pipelines
- ใช้ Path Filters เพื่อเจาะจงไซต์ที่ต้องการ
คุณคงไม่อยากให้การอัปเดตไซต์หนึ่งไปกระตุ้นการ deploy ทั้งสามไซต์ ผมตั้งค่า workflow ของแต่ละไซต์ให้เฝ้าดูเฉพาะโฟลเดอร์ของตัวเองและโฟลเดอร์ shared packages เท่านั้น
ตัวอย่างตรรกะ:
- ไซต์ AI tools จะเฝ้าดูเฉพาะ
apps/ai-tools/ - ไซต์ OSS จะเฝ้าดูเฉพาะ
apps/oss-alternatives/
หากคุณเปลี่ยนโค้ดใน shared directory ทุกไซต์จะ rebuild ผมยอมรับข้อแลกเปลี่ยนนี้เพราะการเปลี่ยนโค้ดที่ใช้ร่วมกันนั้นเกิดขึ้นไม่บ่อยนัก
- เพิ่ม Manual Dispatch เพื่อการควบคุม
Cron จัดการงานประจำวัน ส่วน Manual dispatch จัดการส่วนที่เหลือทั้งหมด ผมใช้ workflow_dispatch เพื่อให้สามารถ:
- Re-run งาน ETL ที่ล้มเหลว
- บังคับให้รีเฟรชหลังจากเพิ่มข้อมูล
- ทำ dry run เพื่อทดสอบข้อมูลโดยไม่เขียนลงในฐานข้อมูล
GitHub UI จะแสดงเมนูแบบ dropdown สำหรับตัวเลือกเหล่านี้ ช่วยป้องกันการพิมพ์ผิดและทำให้การ debug ง่ายขึ้น
Summary
รูปแบบเหล่านี้ไม่ได้ซับซ้อน แต่มันมีความชัดเจน (explicit) ผมเก็บไฟล์ markdown ง่ายๆ ไว้ใน repository เพื่อบันทึกกฎเหล่านี้ เพื่อให้แน่ใจว่าผมจะไม่ทำระบบพังเมื่อมีการเพิ่ม workflow ใหม่ๆ