GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor?
Bakın, küçük görünen ama pratikte gerçekten can yakan bir değişiklikten söz edeceğim: GitHub Actions workflow’ları artık 50 kez yeniden çalıştırma sınırına takılıyor (ki bu çoğu kişinin gözünden kaçıyor). İlk duyduğumda içimden “tamam da kim 50 kere rerun atar ki?” diye geçirdim. Sonra gerçek hayata döndüm — iş değişti. En çok da de de flaky test’ler, dış servislere bağlı entegrasyonlar ve gece yarısı çalışan otomasyonlar devreye girince.
İşin özü şu. Bu tarz limitler genelde bir düşüneyim… kullanıcıyı durdurmak için değil, sistemi korumak için geliyor; yanı kağıt üstünde basit bir sayı gibi dürüyor ama arka planda kaynak tüketimi, kuyruk baskısı ve kontrolsüz retry döngüleri var. Ben bunu ilk kez 2020’de bir finans müşterisinde gördüm — küçük bir pipeline hatası yüzünden aynı iş defalarca rerun ediliyordu ve sabah olduğunda ekip “neden sistem ağırlaştı?” diye birbirine bakıyordu. Kimse suçluyu bulamıyordu çünkü kimse aramıyordu.
Bu limit neden geldi?
İlginç olan şu ki, Düşünsenize şöyle bir senaryo var. Bazı otomasyonlar aynı workflow’u yüzlerce kez tekrar deniyor, platform bunun altında eziliyor. GitHub’ın verdiği mesaj net aslında. Açık konuşayım — bu tip retry fırtınaları çoğu zaman problemi çözmüyor; sadece problemi biraz daha pahalı hâle getiriyor. Hani o meşhur “bir daha deneyelim” yaklaşımı vardır ya? Bazen işe yarar. Çoğunlukla makineyi yorar.
Şunu söyleyeyim, Geçen yıl Mart 2025’te bir üretim müşterisinde benzer bir şey yaşadık. Azure DevOps’tan GitHub Actions’a geçen hibrit yapıda bazı job’lar harici bir API’ye bağlıydı ve API kısa süreli yanıt vermeyince pipeline tekrar tekrar tetikleniyordu, otomatik olarak, kimse fark etmeden. İlk başta “geçici aksaklık” sandık — ama loglara bakınca aynı workflow’un peş peşe döndüğünü gördük. İşte bu limit tam da orada anlam kazanıyor.
Garip gelecek ama, Şunu da söyleyeyim: 50 sayısı kulağa düşük gelebilir ama gerçekçi kullanımda çoğu ekip için yeterli. Eğer bir işi 50’den fazla rerun ile kurtarmaya çalışıyorsanız, sorun büyük ihtimalle workflow tasarımında ya da bağımlılıklarda yatıyordur. Yara bandı yetmez. Biraz dikiş lazım.
50 rerun ne demek? Full re-run ile job seçimi aynı sepette
Burada önemli bir detay var. Çoğu insan bunu kaçırıyor: sınır hem tam yeniden çalıştırmaları hem de seçili job’ların yeniden çalıştırılmasını kapsıyor. “Ben tüm pipeline’ı değil sadece şu iki job’u deniyorum” demek sizi kurtarmıyor — GitHub bunu tek bir çatı altında sayıyor. Öğrendikten sonra “aa, öyle mi?” diyen pek çok ekip gördüm.
Evet, doğru duydunuz.
| Senaryo | Sayaç etkisi | Sahadaki anlamı |
|---|---|---|
| Tüm workflow’u rerun etmek | Evet | Tam yeniden çalışma olarak sayılır |
| Sadece seçili job’ları rerun etmek | Evet | Kısmi rerun da limiti tüketir |
| Aynı workflow’da toplam 51+ deneme | Hayır | Failed check suite ve uyarı gelir |
Limit aşılırsa check suite failed oluyor ve annotation ile size bunun nedeni söyleniyor. Bu kötü mü? Hmm, kısmen evet, kısmen hayır. Kötü tarafı: alışkanlıkla rerun atan ekipler ilk gün biraz afallayacak, bu kesin. İyi tarafı işe sonsuz retry kültürü biraz frenlenmiş olacak — ve bence bu fren geç bile kaldı.
Benim açımdan bu kararın özü şu: CI/CD ortamında “sonsuz sabır” iyi fikir değil. Bir yerde durup sorunu kökünden çözmek gerekiyor; yoksa otomasyon değil, düpedüz retry makinesi kurmuş oluyorsunuz.
Sahada neyi değiştirmeli?
Bu haberi okuyunca aklıma hemen üç konu geldi: flaky test yönetimi, retry stratejisi ve observability. Çünkü limit tek başına problem değil. Asıl problem sizin neden rerun attığınızla ilgili. Eğer testleriniz sürekli patlıyorsa GitHub’a kızmak yerine test stabilitesine bakmak lazım — lafı gevelemeden söylüyorum.
1) Flaky test’leri ayıklayın
2024 sonbaharında Ankara’daki bir e-ticaret ekibiyle yaptığımız değerlendirmede şunu gördük: CI süresinin yüzde 18’i aslında başarısız testlerin tekrar denenmesine gidiyordu. Şaşırdım açıkçası. Peki bunu neden söylüyorum? Testlerin biri saat farkından etkileniyor, biri dış servis çağrısında timeout alıyor, biri de veri seti yüzünden ara sıra sapıtıyordu — yanı klasik üçlü bela, hepsini birden yakaladık.
Şunu söyleyeyim, Böyle durumlarda en iyi çözüm yeni rerun hakkı istemek değil; flaky test’i karantinaya almak, deterministik hâle getirmek ya da mock stratejisini düzeltmek oluyor. AZ-104 ve AZ-305 hazırlıkları sırasında hep söylerim: sağlam mimarı görünürde hız kazandırmaz gibi durur ama uzun vadede en çok zamanı o kurtarır. Bu konu da tam öyle.
2) Retry politikasını kodlayın
Gerçekten transient hata varsa retry mantığı kontrollü olmalı. Körlemesine manuel rerun yerine exponential backoff gibi düzenli bir yaklaşım kullanmak daha temiz — ve daha az sınır bozucu. Mesela ağ tabanlı geçici hata ile derleme hatasını aynı sepete atmayın; biri geçer, diğeri geçmez. Bu ayrımı yapmak önemli.
# Basit düşünce modeli
if error == "transient":
retry(max_attempts=3, backoff="exponential")
else:
fail_fast()
Aslında, Bunu Logosoft tarafında yürüttüğümüz bir kurumsal projede net gördüm; belirli job’lara kontrollü retry koyunca hem işlem süresi düştü hem de ekiplerin panik halinde manuel müdahale etme ihtiyacı ciddi ölçüde azaldı (bu konuda ikircikliyim). Hani bazen küçük bir dokunuş büyük fark yaratır ya… tam da öyle öldü.
3) İzleme olmadan olmaz
Açıkçası, E tabiî metrik meselesi de devreye giriyor burada. Kaç rerun atıldı? Hangi job en çok patlıyor? Hangi branch üzerinde sorun yoğunlaşıyor? Bunları görmeden hareket etmek zor oluyor — aslında neredeyse imkânsız. Zaten benim “Copilot Cloud Agent Metriği” yazısında da anlattığım gibi ölçmediğiniz şeyi iyileştiremezsiniz (buna dikkat edin). Klişe gibi geliyor, biliyorum. Ama doğru.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Küçük ekiplerde başka, enterprise’da başka etkiler var
Aslında, Küçük bir startup için bu limit çoğu zaman görünmez bile olabilir (evet, doğru duydunuz). Zaten günde birkaç düzine — ki bu tartışılır — build alıyorsanız ve süreç disiplinliyse sorun yaşamazsınız. Ama enterprise tarafta işler değişiyor — yüzlerce repo, paralel çalışan release akışları. Gece yarısı otomasyonları derken sınırlar hissedilir hâle geliyor. Epey hissedilir.
Bir bankacılık projesinde bunu açıkça yaşadık. Her takım kendi pipeline mantığını kurmuştu, ortak standart yoktu; bazıları başarısız işi beş kere deniyor, bazıları on kere manuel restart atıyordu (evet, gerçekten on kere). Sonra oturup “hangi durumda kim ne yapacak?” diye kural seti yazdık ve gereksiz tekrarlar ciddi biçimde azaldı. Bazen yazılı kural koymak bu kadar basit etki yaratıyor.
Şimdi gelelim işin can alıcı noktasına.
- Küçük ekip: Limit muhtemelen sorun çıkarmaz ama kötü alışkanlıkları gizleyebilir.
- Büyüyen ürün takımı: Rerun sayısı artarsa flaky test kokusu gelmeye başlar.
- Enterprise: Merkezî politika şart olur; yoksa herkes kendi kafasına göre davranır.
- Düzenli gözlem olan ekip: Limit daha erken fark edilir ve kriz büyümeden çözülür.
Neyse, uzatmayalım. Mesele sadece sayı değil — asıl mesele kültür. Ama “kültür” kelimesi fazla akademik kaçmasın diye şöyle söyleyeyim: herkesin aynı hatayı defalarca tekrar etmesini engelleyen süreç yoksa limit gelir, sonra başka limit gelir, zincir böyle gider.
Bence iyi tarafı ne?
En iyi taraflardan biri platformu koruması kadar ekipleri de disipline etmesi öldü. Ciddi söylüyorum. Bazen insanlar araç rahat olduğu için sorunu ertelemeyi seçiyor — ve bu çok yaygın bir tuzak. GitHub burada hafifçe omza dokunup “dur bakalım” diyor gibi düşünebilirsiniz (inanın bana)
Copilot Code Review metriklerine bakarken de benzer bir şeyi hissetmiştim aslında: ölçüm koyunca davranış değişiyor mu? Evet, değişiyor. Aynı şey burada da var. Limit koyulunca otomatik reflekslerle çalışan ekipler biraz yavaşlıyor ama kalite açısından fena olmayan bir fren etkisi oluşuyor.
Ekşi taraf mı? Var tabiî. Bilhassa karmaşık entegrasyonlarda bazen gerçekten dış bağımlılık kaynaklı geçici sorunlar yaşanabiliyor ve ekibin son çare olarak kullandığı manuel rerun sayısı sınıra dayanabiliyor. O an can sıkıcı. Çünkü beklediğiniz kadar esnek değildir artık sistem.
Peki ben olsam ne yaparım?
İlk iş olarak hangi workflow’ların en çok yeniden çalıştırıldığını çıkarırım. Sonra o işlerin failure pattern’lerine bakarım. Üçüncü adımda başarısızlığı maskeleyen alışkanlıkları keserim — mesela her kırmızı build sonrası körlemesine “rerun all” atan alışkanlık, bence direkt azaltılmalı. Hatta kaldırılmalı.
- Kritik job’lara sahip çıkıp flaky alanları ayıklamak
- Dış servis çağrılarını timeout ve fallback ile güçlendirmek
- Lokal log + artifact + telemetry üçlüsünü birlikte incelemek
- Sadece semptomu değil kök nedeni düzeltmek — bunu es geçmeyin
- Ekip içinde “rerun ne zaman yapılır?” kuralını yazılı hâle getirmek
Buna yakın bir yaklaşımı AZ-500 çalışmalarım sırasında güvenlik taramalarında da görmüştüm; tekrarlayan alarm bastırmak yerine kaynağına inince gürültü azalıyor. Aynı mantık CI/CD’de de çalışıyor. Gerçekten basit görünen şeyler bazen en pahalı operasyon maliyetini yaratıyor — ve bunu geç öğrenmek üzücü oluyor (kendi tecrübem)
Sıkça Sorulan Sorular
GitHub Actions’da neden 50 rerun sınırı var?
Sistem üzerindeki gereksiz yükü azaltmak için kondu.
Tam workflow rerun ile seçili job rerun aynı mı sayılıyor?
Evet, ikisi de toplam limite dahil ediliyor.
Sınırı aşarsam ne olur?
Failed check suite alırsınız ve annotation ile limit aşıldığı belirtilir.
Bunu nasıl önleyebilirim?
Flaky test’leri düzeltin, kontrollü retry kullanın ve gözlemi artırın.
Kullanışlı iç bağlantılar
GitHub Universe Sahneye Çağırıyor Ben Olsam Ne Yaparım?
Kaynaklar ve İleri Okuma
GitHub Blog Changelog — Actions workflows are limited to 50 reruns (evet, doğru duydunuz)
[p>GitHub Actions Limits Documentation]
[p>GitHub Actions Resmî Dokümantasyonu]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
4 comments