Title: GitHub Actions بحال ہو گیا ہے لیکن دستی اصلاحات کی ضرورت ہے

GitHub Actions 7 اگست کو 02:04 UTC پر دوبارہ آن لائن ہو گیا۔ اس تعطل کی وجہ سے push اور pull-request ایونٹس کا ایک سلسلہ پیچھے رہ گیا جو کبھی چل نہیں سکے، اس لیے ڈویلپرز کو ان رنز (runs) کو خود دستی طور پر دوبارہ چلانا ہوگا۔

اسٹیٹس پیج اب سبز نظر آ رہا ہے، لیکن وہ تمام workflows جو تعطل کے دوران شروع ہونے چاہیے تھے، خاموش رہے۔ چونکہ GitHub مس ہوئے ہوئے ٹرگرز (triggers) کو خودکار طریقے سے دوبارہ نہیں چلا سکتا، اس لیے ٹیموں کو نیا commit پش کرنا ہوگا، pull request کو اپ ڈیٹ کرنا ہوگا، یا UI میں Re-run jobs پر کلک کرنا ہوگا۔ اوپن سورس Actions Runner Controller کے صارفین کو یہ بھی چیک کرنے کی ضرورت ہے کہ runner pods بیکار (idle) تو نہیں رہ گئے۔

کیا غلط ہوا اور یہ کیوں اہم ہے

GitHub Actions لاکھوں repos کے CI pipelines کو چلاتا ہے۔ جب یہ رک جاتا ہے، تو کوڈ کی تبدیلیاں رکی رہتی ہیں، ٹیسٹ سویٹس (test suites) نہیں چلتے، اور ڈیپلائمنٹس (deployments) میں تاخیر ہو جاتی ہے۔ 7 اگست کو سروس نے push ایونٹس (نئے commits) اور pull-request ایونٹس (ریویو اپ ڈیٹس) دونوں کی پروسیسنگ روک دی تھی، جو کہ دو سب سے عام CI ٹرگرز ہیں۔

اپنے پائپ لائنز (pipelines) کو کیسے بحال کریں

  1. نیا commit پش کریں – برانچ میں کوئی بھی تبدیلی دوبارہ push ٹرگر کو فعال کر دے گی۔
  2. pull request کو اپ ڈیٹ کریں – PR workflow کو دوبارہ ٹرگر کرنے کے لیے کوئی کمنٹ شامل کریں، عنوان تبدیل کریں، یا مزید commits پش کریں۔
  3. workflow کو دستی طور پر دوبارہ چلائیں – Actions UI اب ہر ناکام رن کے لیے "Re-run jobs" کا بٹن دکھاتا ہے۔

اگر آپ Actions Runner Controller کے ذریعے self-hosted runners چلا رہے ہیں، تو runner pods کا معائنہ کریں۔ سروس کی واپسی کے بعد کچھ pods بیکار (idle) رہ سکتے ہیں؛ انہیں ری اسٹارٹ یا ری ڈیپلائے کریں۔

ٹیموں کے لیے اثرات

  • پیداواری صلاحیت کا نقصان – ڈویلپرز اس فیڈ بیک کا انتظار کرتے ہیں جو عام طور پر منٹوں میں آ جاتا ہے۔
  • ریلیز میں تاخیر – کوئی بھی پائپ لائن جو ریلیز کو روک رہی ہو، شپنگ کی تاریخوں کو آگے دھکیل سکتی ہے۔
  • آپریشنل بوجھ – ٹیموں کو حالیہ رنز کا آڈٹ کرنا، خامیوں کی نشاندہی کرنا، اور اوپر دیے گئے دستی اقدامات کرنے ہوں گے، جس سے فیچر ورک کے لیے دستیاب وقت کم ہو جائے گا۔

خلاصہ: یہ تعطل ظاہر کرتا ہے کہ پختہ (mature) CI سروسز بھی جابز (jobs) کو چھوڑ سکتی ہیں، اور خودکار ری پلے کی ضمانت نہیں دی جا سکتی۔ اپنے incident-response playbooks میں دستی بحالی کے اقدامات شامل کریں اور ایونٹ ہینڈلنگ کو مزید مستحکم بنانے کی طرف GitHub کے اگلے اقدامات پر نظر رکھیں۔