GitHub Actions zamanlanmış workflow'ları sessizce çalışmayı atlayabiliyor — çözüm dış bir zamanlayıcı olabilir

Hiç gerçekleşmeyen zamanlanmış çalışmalar

Dev.to'daki bir yazı, bir kullanıcının saatlik bir GitHub Actions workflow'unun basitçe çalışma üretmeyi bıraktığını bildirdiği bir GitHub Community tartışmasını (başlık #207247) belgeliyor. Workflow cron ifadesi 17 * * * * kullanıyordu, ancak beklenen birkaç ardışık çalıştırma hiç gerçekleşmedi — ve hiçbir çalışmaya dair iz yoktu. Hiçbir şey başarısız olmadı, kuyruğa girmedi, iptal edilmedi: zamanlanmış olay hiç oluşturulmadı.

Dev.to makalesine göre, başlığı açan jessie-mele workflow'u workflow_dispatch ile manuel olarak tetiklemeyi sürdürebiliyordu ve bu çalışmalar başarıyla tamamlanıyordu. Bu, workflow'un mantığındaki, job'larındaki veya runner atamasındaki sorunları elerdi ve şüpheyi doğrudan olay tetikleyicisinin kendisine yöneltti. Kullanıcı, yoğun yükten kaçınmak için zamanlamayı zaten saat başından uzaklaştırmıştı — 0 * * * * ifadesinden 17. dakikaya — ancak atlamalar sürdü ve gerçekleşen çalışmalarda bazen ciddi gecikmeler yaşandı.

Best-effort bir zamanlayıcı

Başlıktaki yanıt verenlerden TongyiDai ve Dotoryman da dahil olmak üzere herkes, hatanın kaynağında GitHub'ın zamanlayıcısında olduğu konusunda hemfikirdi. Tartışmada alıntılanan GitHub dokümantasyonu, zamanlanmış olayları "best-effort" olarak tanımlıyor: yeterli yük altında gecikebilir veya tamamen düşürülebilirler; tıkanıklık, çok sayıda cron job'ının aynı anda tetiklendiği her saatin başında yoğunlaşıyor.

Ara sıra yaşanan gecikmeli bir çalışma normal bir sapmadır. Dev.to yazısının da belirttiği gibi, art arda beş eksik saatlik tetikleyici, daha yapısal bir şeye işaret eder — zamanlama olayını çalıştırmakla ilgili bir sorun değil, o olayı hiç üretmemiş olmakla ilgili bir sorundur bu.

Sessiz bir zamanlamayı tanılama

Topluluğun ilk savunma hattı, workflow'u GitHub'ın zamanlayıcısı üzerine geri zorlamayı amaçlayan bir dizi kontrol:

• GitHub CLI ile workflow'un ve repository'nin durumunu inceleyin — workflow'un aktif olduğunu, default branch'in doğru olduğunu ve arşivlenmiş ya da devre dışı bırakılmış bir işaret bulunmadığını doğrulayın.
• Eksik zaman aralıklarında hiçbir run kaydının olmadığını doğrulamak için, çalışmaları schedule olayına göre filtreleyerek son çalışanları listeleyin.
• Workflow'u disable ve enable komutlarıyla kapatıp yeniden açın; bu, GitHub'ı onu yeniden kaydetmeye yönlendirebilir.
• Cron ifadesinde default branch üzerinde gerçek bir değişiklik yapın — örneğin 17. dakikadan 23. dakikaya geçin — bu da genellikle GitHub'ın zamanlamayı yeniden değerlendirmesini ve kaydetmesini sağlar. Başlıkta, geçici bir çözüm olarak art arda boş commit'lere bel bağlamama konusunda uyarı yapılıyor.

GitHub Support'a başvurma

Tüm bunlardan sonra zamanlanmış çalışmalar hâlâ gerçekleşmiyorsa, dev.to makalesi açık konuşuyor: bu, repository tarafında daha fazla yapılandırmayla çözülemez ve bir sonraki adım bir destek talebidir. Ancak bir pürüz var: Repository'nizde, zamanlayıcının hiç üretmediği bir olayın kaydı bulunmaz; dolayısıyla GitHub'ın araştırmacıları tamamen sizin sunduğunuz kanıtlara güvenir. Önerilen destek talebi içeriği şunları kapsıyor: workflow ID'si ve repository URL'si, çalışmaların beklenip hiç oluşturulmadığı kesin UTC zaman aralıkları, son başarılı zamanlanmış çalışmanın zaman damgası, workflow'un kendisinin sağlıklı olduğunun kanıtı olarak yakın tarihli başarılı bir workflow_dispatch çalışmasının bağlantısı, eksik slotlarda hiçbir run veya job kaydının bulunmadığına dair açık bir ifade ve yapılan tüm disable/enable döngülerinin veya cron düzenlemelerinin zaman damgaları.

Sınırlamayı hesaba katarak tasarım

Makalenin çıkardığı daha geniş ders mimaridir. Kesin teslimat gereksinimleri olan saatlik job'lar için, workflow'un önüne dış bir zamanlayıcı yerleştirilmesini öneriyor — örnek olarak özel bir cron servisi, AWS EventBridge veya Azure Logic Apps gösteriliyor — ve bunun workflow_dispatch çağırması sağlanıyor. Böylece teslimat garantisi, sizin kontrol ettiğiniz ve bağımsız olarak izleyebildiğiniz bir sisteme geçer; workflow mantığı ise Actions içinde kalır.

Neden önemli

Zamanlanmış workflow'lar sessizce büyük bir operasyonel yük taşır: bağımlılık güncellemeleri, gece test paketleri, yedeklemeler ve release otomasyonunun hepsi tetikleyicinin ateşleneceğini varsayar. Bir zamanlayıcı olayları sessizce düşürdüğünde, hiçbir şey gürültülü biçimde başarısız olmaz — pipeline sadece çalışmaz ve ilk belirti günler sonra eskiyen bağımlılıklar veya kaçırılmış bir zaman aralığı olarak ortaya çıkabilir. GitHub'ın yerel zamanlamasının açıkça best-effort olduğunu bilmek, ekiplerin hangi görevleri ona emanet edeceğini şekillendirmelidir. Topluluk başlığı, hem sorun ortaya çıktığında uygulanacak pratik bir runbook hem de tek bir çalışmayı bile kaçıramayacak pipeline'lar için net bir desen — dış zamanlayıcı artı workflow_dispatch — sunuyor.