Title: بازگشت GitHub Actions؛ اما اصلاحات دستی همچنان مورد نیاز است
سرویس GitHub Actions در تاریخ ۷ اوت، ساعت ۰۲:۰۴ UTC دوباره آنلاین شد. این قطعی باعث شد مجموعهای از رویدادهای push و pull-request که باید اجرا میشدند، اجرا نشوند؛ بنابراین توسعهدهندگان باید این اجراها را به صورت دستی دوباره اجرا کنند.
صفحه وضعیت (status page) اکنون سبز است، اما هر workflow که باید در طول زمان قطعی شروع میشد، بدون اجرا باقی مانده است. از آنجایی که GitHub نمیتواند triggerهای از دست رفته را به صورت خودکار بازنشانی (replay) کند، تیمها باید یک commit جدید push کنند، pull request را بهروزرسانی کنند و یا در رابط کاربری روی گزینه Re-run jobs کلیک کنند. کاربران Actions Runner Controller (نسخه متنباز) نیز باید بررسی کنند که podهای runner در حالت idle گیر نکرده باشند.
چه مشکلی پیش آمد و چرا اهمیت دارد
GitHub Actions موتور محرک خط لولههای (pipelines) CI در میلیونها مخزن (repo) است. وقتی این سرویس متوقف میشود، تغییرات کد معطل میمانند، مجموعههای تست اجرا نمیشوند و زمانبندی استقرار (deployment) به تأخیر میافتد. در تاریخ ۷ اوت، این سرویس پردازش هر دو رویداد push (commitهای جدید) و pull-request (بهروزرسانیهای بررسی) را که دو trigger رایج در CI هستند، متوقف کرد.
چگونه خط لولههای خود را بازیابی کنید
- Push کردن یک commit جدید – هر تغییری در branch باعث فعال شدن مجدد trigger مربوط به push میشود.
- بهروزرسانی pull request – یک کامنت اضافه کنید، عنوان را تغییر دهید یا commitهای بیشتری push کنید تا workflow مربوط به PR دوباره فعال شود.
- اجرای مجدد دستی workflow – رابط کاربری Actions اکنون برای هر اجرای ناموفق، دکمه “Re-run jobs” را نمایش میدهد.
اگر از runnerهای self-hosted از طریق Actions Runner Controller استفاده میکنید، podهای runner را بررسی کنید. ممکن است برخی از آنها پس از بازگشت سرویس در حالت idle باقی بمانند؛ آنها را ریاستارت یا دوباره مستقر (redeploy) کنید.
پیامدهای این اتفاق برای تیمها
- کاهش بهرهوری – توسعهدهندگان منتظر بازخوردی میمانند که معمولاً در عرض چند دقیقه دریافت میشود.
- تأخیر در انتشار – هر خط لولهای که مانع انتشار (release) شود، میتواند تاریخهای تحویل محصول را به عقب براند.
- بار عملیاتی اضافی – تیمها باید اجراهای اخیر را بازبینی کنند، شکافها را شناسایی کنند و مراحل دستی ذکر شده در بالا را انجام دهند که این امر زمان اختصاص یافته به توسعه ویژگیهای جدید را کاهش میدهد.
نکته کلیدی: این قطعی نشان میدهد که حتی سرویسهای بالغ CI نیز ممکن است اجراها (jobs) را از دست بدهند و بازنشانی خودکار تضمینشده نیست. مراحل بازیابی دستی را در دستورالعملهای پاسخ به حادثه (incident-response playbooks) خود بگنجانید و گامهای بعدی GitHub را برای مدیریت منعطفتر رویدادها دنبال کنید.