Rongchai Wang
17 stycznia 2026 09:16
GitHub wprowadza ograniczenie liczby przesyłanych wpisów cache Actions do 200 na minutę na repozytorium, rozwiązując problemy ze stabilnością systemu wynikające z dużej liczby przesyłanych plików.
GitHub wdrożył nowy limit częstotliwości dla swojego systemu cache Actions, ograniczając przesyłanie do 200 nowych wpisów cache na minutę dla każdego repozytorium. Zmiana ogłoszona 16 stycznia 2026 roku jest skierowana do repozytoriów, które bombardowały system cache szybkimi przesyłaniami i powodowały problemy ze stabilnością na całej platformie.
Pobieranie pozostaje nienaruszone. Jeśli Twoje workflow pobierają istniejące wpisy cache, nic się nie zmienia. Limit dotyczy konkretnie tworzenia nowych wpisów — rozróżnienie istotne dla zespołów uruchamiających równoległe buildy generujące świeże dane cache.
Dlaczego teraz? GitHub wskazał „cache thrash" jako winowajcę. Repozytoria przesyłające ogromne ilości wpisów cache w krótkich seriach obniżały wydajność dla wszystkich innych na współdzielonej infrastrukturze. Limit 200 na minutę daje intensywnym użytkownikom wystarczającą przestrzeń dla uzasadnionych przypadków użycia, jednocześnie zapobiegając nadużyciom, które destabilizowały system.
Część szerszej przebudowy Actions
Ten limit częstotliwości pojawia się w środku kilku znaczących zmian w ekonomii GitHub Actions. Na początku tego miesiąca GitHub obniżył ceny hostowanych runnerów o 15% do 39% w zależności od rozmiaru. Ale większą wiadomością jest 1 marca 2026 roku, kiedy korzystanie z samodzielnie hostowanych runnerów w prywatnych repozytoriach zacznie kosztować 0,002 USD za minutę — nowa opłata, która skłania niektóre zespoły do ponownego przemyślenia całej architektury CI/CD.
Sam system cache otrzymał uaktualnienie pod koniec 2025 roku, a repozytoria mogą teraz przekroczyć poprzedni limit 10 GB dzięki cenom płatnym za użycie. Każde repozytorium nadal otrzymuje 10 GB za darmo, ale intensywni użytkownicy mogą teraz kupić więcej, zamiast ciągle walczyć z polityką wykluczania.
Co zespoły powinny sprawdzić
Większość workflow nie zauważy tego limitu. Ale jeśli uruchamiasz buildy macierzowe generujące unikalne klucze cache dla dziesiątek równoległych zadań, policz to. Macierz 50 zadań kończąca się jednocześnie może teoretycznie osiągnąć 200 przesyłań cache w niecałą minutę, jeśli każde zadanie tworzy wiele wpisów.
Rozwiązanie jest proste: skonsoliduj klucze cache tam, gdzie to możliwe, lub rozłóż w czasie zakończenie zadań, jeśli naprawdę uderzasz w limit. GitHub nie ogłosił żadnego panelu monitorowania częstotliwości przesyłania cache, więc zespoły obawiające się osiągnięcia limitów będą musiały ręcznie audytować swoje logi workflow.
Źródło obrazu: Shutterstock
Źródło: https://blockchain.news/news/github-actions-cache-rate-limit-200-per-minute
