GitHub, 25 Eylül 2026'da eski self-hosted runner'lara iş kuyruklamayı durduruyor

dev.to'da yayımlanan bir yazıya göre, eski sürümleri kullanan self-hosted GitHub Actions runner'ları 25 Eylül 2026'da kalıcı olarak iş almayı bırakacak. Bu tarihten önce GitHub, 7, 9, 11, 14, 16 ve 18 Eylül'de brownout'lar düzenliyor; bu sürelerde eski runner'lar ne kayıt olabiliyor ne de iş çalıştırabiliyor.

Hata sessizce gerçekleşiyor

Yazının merkezindeki uyarı, bu kopmanın gözden kaçırılmasının çok kolay olduğudur. Workflow'lar görünür bir hatayla başarısız olmuyor; eski bir runner'ı hedefleyen her iş basitçe "Queued" durumunda bekliyor ve en net sinyal, runner sürümünün kullanımdan kaldırıldığını ve mesaj alamayacağını belirten bir runner log satırı.

Yazar, Actions Runner Controller (ARC) kullanan ekiplerin özellikle risk altında olduğunu belirtiyor, çünkü ARC tasarımı gereği otomatik güncellemeyi devre dışı bırakıyor. Helm değerlerinde sabitlenmiş (pinned) bir image etiketi, aslında kimsenin tarihe bakmadığı planlanmış bir kesinti.

GitHub bir deprecation API'si yayımladı

3 Eylül 2026'da GitHub, herhangi bir runner sürümü için kullanım ömrü bitiş tarihlerini döndüren bir endpoint ekledi. 2.334.0 gibi bir sürümle çağrıldığında, runtime desteğinin sona ereceği tarihi ve kaydın sona ereceği tarihi birlikte döndürüyor.

Yazar, API'yi gerçek sürümler üzerinde çalıştırarak iki bulgu paylaşıyor. Birincisi, belgelerdeki kural desteğin yayımdan 30 gün sonra sona ermesi olsa da, API şu anda yakın tarihli sürümler için kabaca 63 ila 71 gün döndürüyor; dolayısıyla yayım tarihlerinden hesaplanan son kullanma tarihleri her iki yönde de yanlış. İkincisi, runner listeleme endpoint'i artık her runner'ın sürümünü içeriyor, böylece bir denetim için makinelerde agent kurulu olması gerekmiyor.

Canlı runner'ların ve sabitlenmiş sürümlerin denetlenmesi

Endpoint'leri pratik kılmak için yazar, MIT lisansıyla açık kaynak bir gh extension olan gh-runner-eol'u yayımladı. Organizasyon genelinde bir denetim, canlı runner'ları sürüme göre gruplandırıyor ve her grubu gecikmiş, uyarı veya tamam olarak işaretliyor. Yazarın örnek çıktısında 43 runner üç sürüm çalıştırıyordu: runtime desteği 10 Ağustos 2026'da sona eren v2.334.0'da 18 tanesi; desteği 15 Eylül 2026'da sona erecek v2.336.0'da 12 tanesi; ve kullanım ömrü bitiş tarihi planlanmamış v2.337.0'da 13 tanesi.

Extension'ın tarama modu ayrıca sabitlenmiş sürümler için Dockerfile'ları, ARC Helm değerlerini, RUNNER_VERSION değişkenlerini ve indirme URL'lerini grep'liyor ve her birini API üzerinden çözümlüyor. Bu, yalnızca yapılandırma olarak var olan runner'ları — henüz ölçeklendirilmemiş image'leri — kapsıyor; bunları canlı runner panosu göremez.

Ayrıca SARIF çıktısıyla bir GitHub Action olarak çalışabiliyor; böylece sabitlenmiş bir sürüm, onu tanıtan pull request üzerinde bir Code Scanning açıklaması olarak görünüyor ve gecikmiş sonuçlarda sıfır olmayan bir çıkış kodu döndürüyor, böylece haftalık bir zamanlama alarm tetikleyebiliyor.

Token ve kapsam uyarıları

Varsayılan workflow GITHUB_TOKEN'ı self-hosted runner'ları okuyamıyor ve 403 döndürüyor; bu nedenle extension, organizasyon düzeyinde self-hosted runner okuma izni olan ya da depo düzeyinde administration okuma izni olan ince ayarlı bir PAT'ye veya GitHub App token'ına ihtiyaç duyuyor. Yalnızca tarama modu bunların hiçbiri olmadan çalışıyor. Araç ayrıca bilinçli olarak salt okunur: neyin ne zaman bozulacağını yanıtlıyor; gerçek yükseltmeyi ARC, GARM ve benzeri araçlar hallediyor.

Neden önemli

25 Eylül, yavaş bir bakım işini katı bir son tarihe dönüştürüyor. O tarihten sonra, eski bir self-hosted runner'ı hedefleyen workflow'lar sesli bir hatayla başarısız olmak yerine süresiz olarak kuyrukta bekleyecek — ekiplerin geç fark ettiği türden bir kesinti. 7 Eylül'den itibaren yapılacak brownout'lar bir önizleme sunuyor, ama yalnızca altı gün boyunca.

Çözümün kendisi basit: runner'ları güncelleyin ve bayat ARC image etiketlerini sabitlemeyi bırakın. Asıl iş, organizasyondaki her etkilenen runner'ı ve her sabitlenmiş sürümü bulmak; yeni deprecation API'si ve denetim araçları da bu boşluğu kapatıyor. Belgelerdeki 30 günlük süre ile API'nin gerçekte döndürdüğü 63 ila 71 gün arasındaki uyumsuzluk, son kullanma tarihlerini yayım takvimlerinden elle hesaplamayı bırakmak için bir neden daha.