Title: GitHub Actions przywrócone, ale wymagane są ręczne poprawki

Usługa GitHub Actions została przywrócona o godzinie 02:04 UTC dnia 7 sierpnia. Awaria pozostawiła po sobie szereg zdarzeń typu push oraz pull-request, które nigdy się nie uruchomiły, w związku z czym programiści muszą ręcznie powtórzyć te procesy.

Strona statusu wyświetla już kolor zielony, ale każdy workflow, który powinien uruchomić się w trakcie awarii, pozostał nieaktywny. Ponieważ GitHub nie potrafi automatycznie powtórzyć pominiętych wyzwalaczy (triggers), zespoły muszą wypchnąć nowy commit, zaktualizować pull request lub kliknąć Re-run jobs w interfejsie użytkownika. Użytkownicy open-source'owego Actions Runner Controller muszą również sprawdzić, czy pody runnerów nie utknęły w stanie bezczynności.

Co poszło nie tak i dlaczego ma to znaczenie

GitHub Actions napędza potoki CI (CI pipelines) milionów repozytoriów. Gdy usługa staje, zmiany w kodzie pozostają nieprzetworzone, zestawy testów nie są uruchamiane, a wdrożenia ulegają opóźnieniu. 7 sierpnia usługa przestała przetwarzać zarówno zdarzenia push (nowe commity), jak i pull-request (aktualizacje recenzji), które są dwoma najczęstszymi wyzwalaczami CI.

Jak przywrócić działanie potoków

  1. Wypchnij nowy commit – każda zmiana w gałęzi ponownie uruchomi wyzwalacz push.
  2. Zaktualizuj pull request – dodaj komentarz, zmień tytuł lub wypchnij kolejne commity, aby ponownie wywołać workflow PR.
  3. Uruchom workflow ręcznie – interfejs Actions wyświetla teraz przycisk „Re-run jobs” dla każdego nieudanego uruchomienia.

Jeśli korzystasz z self-hosted runnerów za pomocą Actions Runner Controller, sprawdź pody runnerów. Niektóre mogą pozostać bezczynne po przywróceniu usługi; należy je zrestartować lub ponownie wdrożyć.

Skutki dla zespołów

  • Utrata produktywności – programiści czekają na informacje zwrotne, które zazwyczaj docierają w ciągu kilku minut.
  • Opóźnienia w wydaniach – każdy potok blokujący wydanie (release) może przesunąć daty dostarczenia produktu.
  • Obciążenie operacyjne – zespoły muszą audytować ostatnie uruchomienia, wykrywać luki i wykonywać powyższe kroki ręcznie, co zabiera czas przeznaczony na pracę nad nowymi funkcjonalnościami.

Wniosek: Awaria pokazuje, że nawet dojrzałe usługi CI mogą gubić zadania, a automatyczne powtarzanie nie jest gwarantowane. Uwzględnij kroki ręcznego odzyskiwania w swoich playbookach reagowania na incydenty (incident-response playbooks) i obserwuj kolejne działania GitHub zmierzające ku bardziej odpornej obsłudze zdarzeń.