Monorepo ETL साठी 4 GitHub Actions पॅटर्न
एकाच monorepo मधून तीन साइट्स चालवल्यामुळे समस्या निर्माण होतात. तुम्हाला तीन वेगळे ETL जॉब्स, तीन कंटेंट रिबिल्ड्स आणि तीन डिप्लॉयमेंट पाइपलाइन्सचा सामना करावा लागतो. जर तुम्ही त्यांचे समन्वय साधला नाही, तर ते एकमेकांशी टकरातात (collide).
ही सेटअप स्थिर करण्यासाठी मी सहा आठवडे वेळापत्रकांचे (schedules) परीक्षण केले. मी वापरत असलेले चार पॅटर्न खालीलप्रमाणे आहेत.
- Cron Jobs साठी Time Offsets वापरा
सर्व ETL जॉब्स एकाच वेळी चालवल्यामुळे त्रुटी (failures) येतात. जॉब्स API rate limits साठी स्पर्धा करतात. जेव्हा HuggingFace किंवा GitHub 429 एरर देते, तेव्हा रन फेल होते.
हे टाळण्यासाठी मी 30 मिनिटांचे offsets वापरतो.
- पहिला जॉब 02:00 ला सुरू होतो
- दुसरा जॉब 02:30 ला सुरू होतो
- तिसरा जॉब 03:00 ला सुरू होतो
पुढचा जॉब सुरू होण्यापूर्वी एखादा मोठा 'pull' पूर्ण करण्यासाठी तीस मिनिटे पुरेसा वेळ आहे. यामुळे तुमचे लॉग्स (logs) स्वच्छ राहतात आणि API collisions टाळता येतात.
- अनावश्यक रिबिल्ड्स थांबवण्यासाठी Skip Flags वापरा
प्रत्येक ETL जॉबचा शेवट Vercel डिप्लॉयमेंटने होतो. जेव्हा आर्टिकल कमिट्समुळे (article commits) रिबिल्ड्स ट्रिगर होतात, तेव्हा समस्या निर्माण होते. योग्य नियोजनाशिवाय, प्रत्येक आर्टिकल अपडेटमुळे तिन्ही साइट्सना रिबिल्ड करावे लागते. यामुळे बिल्ड मिनिट्स वाया जातात.
मी ETL कमिट मेसेजमध्ये [skip publish-articles] टॅग वापरतो.
मी माझ्या वर्कफ्लोमध्ये हा फ्लॅग तपासण्यासाठी एक स्टेप जोडली आहे. जर तो टॅग असेल, तर वर्कफ्लो बिल्ड आणि डिप्लॉय स्टेप वगळतो (skips). यामुळे ETL पाइपलाइन्स आर्टिकल पाइपलाइन्सपासून वेगळ्या राहतात.
- विशिष्ट साइट्स टार्गेट करण्यासाठी Path Filters वापरा
तुम्हाला एका साइटच्या अपडेटमुळे तीन डिप्लॉयमेंट्स ट्रिगर होतील असे वाटणार नाही. मी प्रत्येक साइटचा वर्कफ्लो फक्त स्वतःचा फोल्डर आणि shared packages फोल्डर पाहण्यासाठी (watch) कॉन्फिगर करतो.
उदाहरण लॉजिक:
- AI tools साइट फक्त
apps/ai-tools/पाहते - OSS साइट फक्त
apps/oss-alternatives/पाहते
जर तुम्ही shared डिरेक्टरीमध्ये कोड बदलला, तर सर्व साइट्स रिबिल्ड होतील. मी हा तडजोड (trade-off) स्वीकारतो कारण shared कोडमधील बदल दुर्मिळ असतात.
- नियंत्रणासाठी Manual Dispatch जोडा
Cron दैनंदिन कामे हाताळते. Manual dispatch इतर सर्व गोष्टी हाताळते. मी workflow_dispatch वापरतो जेणेकरून मी:
- फेल झालेला ETL जॉब पुन्हा चालवू (Re-run) शकतो
- डेटा जोडल्यानंतर फोर्स रिफ्रेश (Force refresh) करू शकतो
- डेटाबेसमध्ये डेटा न लिहिता डेटा तपासण्यासाठी 'dry run' करू शकतो
GitHub UI या निवडींसाठी ड्रॉपडाउन मेनू दाखवते. यामुळे टायपिंगच्या चुका (typos) टाळता येतात आणि डीबगिंग (debugging) सोपे होते.
सारांश
हे पॅटर्न क्लिष्ट नाहीत. ते स्पष्ट आहेत. मी या नियमांचे दस्तऐवजीकरण करण्यासाठी माझ्या रिपॉझिटरीमध्ये एक साधी markdown फाईल ठेवतो. यामुळे जेव्हा मी नवीन वर्कफ्लो जोडतो, तेव्हा सिस्टममध्ये बिघाड होणार नाही याची खात्री मिळते.