4 GitHub Actions Patterns for Monorepo ETL
ایک ہی monorepo سے تین سائٹس چلانے سے مسائل پیدا ہوتے ہیں۔ آپ کو تین الگ الگ ETL جابز، مواد کی تین بار ری بلڈ (rebuild) اور تین ڈیپلائمنٹ پائپ لائنز کا سامنا کرنا پڑتا ہے۔ اگر آپ ان میں ہم آہنگی پیدا نہیں کرتے، تو یہ آپس میں ٹکرا جاتی ہیں۔
میں نے اس سیٹ اپ کو مستحکم کرنے کے لیے شیڈولز کی جانچ پڑتال میں چھ ہفتے صرف کیے۔ یہاں وہ چار پیٹرنز ہیں جو میں استعمال کرتا ہوں۔
- Cron Jobs کے لیے Time Offsets کا استعمال کریں
تمام ETL جابز کو ایک ہی وقت میں چلانے سے ناکامی کا سامنا کرنا پڑتا ہے۔ جابز API rate limits کے لیے مقابلہ کرتی ہیں۔ جب HuggingFace یا GitHub 429 error واپس کرتا ہے، تو رن (run) فیل ہو جاتا ہے۔
میں اس سے بچنے کے لیے 30 منٹ کے آفسیٹس (offsets) استعمال کرتا ہوں۔
- پہلی جاب 02:00 پر شروع ہوتی ہے
- دوسری جابی 02:30 پر شروع ہوتی ہے
- تیسری جاب 03:00 پر شروع ہوتی ہے
اگلی جاب شروع ہونے سے پہلے ایک بھاری پل (pull) مکمل کرنے کے لیے تیس منٹ کافی وقت ہے۔ یہ آپ کے لاگز (logs) کو صاف رکھتا ہے اور API ٹکراؤ (collisions) کو روکتا ہے۔
- غیر ضروری ری بلڈز کو روکنے کے لیے Skip Flags کا استعمال کریں
ہر ETL جاب کا اختتام Vercel ڈیپلائمنٹ پر ہوتا ہے۔ مسئلہ تب پیدا ہوتا ہے جب آرٹیکل کمٹس (article commits) بھی ری بلڈز کو ٹرگر کرتے ہیں۔ کسی منصوبے کے بغیر، ہر آرٹیکل اپ ڈیٹ تمام تینوں سائٹس کو ری بلڈ کرنے پر مجبور کرتی ہے۔ اس سے بلڈ منٹ (build minutes) ضائع ہوتے ہیں۔
میں ETL کمٹ میسجز میں ایک [skip publish-articles] ٹیگ استعمال کرتا ہوں۔
میں نے اس فلیگ کو چیک کرنے کے لیے اپنے ورک فلو (workflow) میں ایک مرحلہ شامل کیا ہے۔ اگر ٹیگ موجود ہو، تو ورک فلو بلڈ اور ڈیپلائمنٹ کے مرحلے کو چھوڑ (skip) دیتا ہے۔ یہ ETL پائپ لائنز کو آرٹیکل پائپ لائنز سے الگ رکھتا ہے۔
- مخصوص سائٹس کو ٹارگٹ کرنے کے لیے Path Filters کا استعمال کریں
آپ نہیں چاہیں گے کہ ایک سائٹ کی اپ ڈیٹ تین ڈیپلائمنٹس کو ٹرگر کرے۔ میں ہر سائٹ کے ورک فلو کو صرف اپنے فولڈر اور شیئرڈ پیکجز (shared packages) فولڈر پر نظر رکھنے کے لیے کنفیگر کرتا ہوں۔
مثالی منطق (Example logic):
- AI tools سائٹ صرف apps/ai-tools/ کو دیکھتی ہے
- OSS سائٹ صرف apps/oss-alternatives/ کو دیکھتی ہے
اگر آپ شیئرڈ ڈائریکٹری میں کوڈ تبدیل کرتے ہیں، تو تمام سائٹس ری بلڈ ہوں گی۔ میں اس سمجھوتے (trade-off) کو قبول کرتا ہوں کیونکہ شیئرڈ کوڈ میں تبدیلیاں کم ہی ہوتی ہیں۔
- کنٹرول کے لیے Manual Dispatch شامل کریں
Cron روزمرہ کے معمولات کو سنبھالتا ہے۔ Manual dispatch باقی سب کچھ سنبھالتا ہے۔ میں workflow_dispatch استعمال کرتا ہوں تاکہ میں:
- ناکام ETL جاب کو دوبارہ چلانا
- ڈیٹا شامل کرنے کے بعد ریفریش کرنے پر مجبور کرنا
- ڈیٹا بیس میں لکھے بغیر ڈیٹا کو ٹیسٹ کرنے کے لیے ڈرائی رن (dry run) چلانا
GitHub UI ان انتخاب کے لیے ایک ڈراپ ڈاؤن مینو دکھاتا ہے۔ یہ ٹائپنگ کی غلطیوں (typos) کو روکتا ہے اور ڈی بگنگ (debugging) کو آسان بناتا ہے۔
خلاصہ
یہ پیٹرنز پیچیدہ نہیں ہیں۔ یہ واضح ہیں۔ میں ان قواعد کو دستاویز کرنے کے لیے اپنی ریپوزٹری میں ایک سادہ مارک ڈاؤن فائل رکھتا ہوں۔ اس سے یہ یقینی بنتا ہے کہ جب میں نئے ورک فلو شامل کروں تو سسٹم خراب نہ ہو۔