Self-hosted runner’ı şimdi denetleyin; sabit 2.329.0 sürümü yetmiyor

Self-hosted runner filosunu yalnızca 2.329.0 ile karşılaştırmak yeterli değildir. Enterprise, kuruluş ve depo kapsamındaki runner’ları REST API ile listeleyin, her sürümün çalışma desteğini ayrı denetleyin ve kapasiteyi yeni bir kohorta taşıyarak eski düğümleri kademeli biçimde yenileyin.

2.329.0, runner’ı kaydetmek veya yeniden kaydetmek için taban sürümdür; kalıcı çalışma tabanı değildir. GitHub’ın yaptırım takvimi, her yeni major, minor veya patch sürümünün 30 günlük güncelleme penceresini başlattığını ve süresi geçen runner’a iş kuyruğa alınmayacağını belirtiyor; kritik güvenlik güncellemesinde kuyruk daha erken durdurulabilir. Bu politika github.com üzerindeki GitHub Enterprise Cloud ortamlarını kapsıyor, GitHub Enterprise Server’ı ise kapsamıyor.

Kayıt tabanı ile çalışma tabanını ayırın

Kayıt tabanı, runner’ın hizmete kaydolabilmesi için gereken en düşük sürümdür. Çalışma tabanı ise mevcut runner’ın yeni workflow işlerini almaya devam edip edemeyeceğini belirler ve yeni sürümler yayımlandıkça ilerler. Dolayısıyla “2.329.0 veya üzeri” kontrolü, runner’ın bugün desteklenen çalışma aralığında bulunduğunu tek başına kanıtlamaz.

Denetim çıktısında iki ayrı sonuç üretin: “kayıt için uygun” ve “çalışma için destekleniyor”. Bunların yanına sürüm desteğinin sona ereceği zamanı ve filonun kullandığı kurulum kaynağını ekleyin. Böylece çalışan makineyi elle yükseltip VM imajını, container imajını veya başlangıç betiğini eski sürümde bırakma hatası görünür olur.

API’den eksiksiz filo envanteri çıkarın

Yetkinizin bulunduğu en geniş kapsamdan başlayın: enterprise için GET /enterprises/{enterprise}/actions/runners, kuruluş için GET /orgs/{org}/actions/runners, depoya kayıtlı runner’lar için GET /repos/{owner}/{repo}/actions/runners çağrısını kullanın. Resmî REST API referansı, yanıtta id, name, os, status, busy, ephemeral, version ve labels alanlarını tanımlıyor; sayfa başına üst sınır 100 olduğundan bütün sayfalar alınmadan envanter tamamlanmış sayılmaz.

Her kayıt için runner kimliğini, adını, kapsamını, sürümünü, işletim sistemini, etiketlerini, çevrim içi durumunu ve meşguliyet bilgisini saklayın. Envanter zamanını ve gönderdiğiniz X-GitHub-Api-Version: 2026-03-10 başlığını da kayda ekleyin. Runner grubu veya altyapı havuzu API yanıtında açıkça bulunmuyorsa bu eşlemeyi dağıtım envanterinizden tamamlayın; etiketten tahmin üretmeyin.

Envanterdeki her farklı sürümü aynı kapsamdaki GET .../actions/runners/deprecations/{version} uç noktasıyla sorgulayın. Dönen runner_version ve runtime_deprecates_at değerlerini sürüm tablosuna işleyin. Aynı sürümü yüzlerce runner için tekrar sorgulamak yerine sürüm başına tek sonuç üretip ilgili kayıtlara uygulayın.

Güncelleme sırasını kapasite riskine göre kurun

Önceliği çalışma desteği sona ermiş veya sona yaklaşmış sürümlere verin. Ardından otomatik güncellemesi kapalı kalıcı düğümleri ve eski imajlardan yeniden oluşturulan runner’ları ele alın. Çevrim dışı runner’ları listeden sessizce çıkarmayın: geri dönmeyecek makinelerin kaydını temizleyin, yeniden başlayabilecek makinelerin ise kurulum kaynağını düzeltin.

Filoyu işletim sistemi, mimari, runner grubu, özel donanım ve workflow etiketlerine göre kohortlara ayırın. GPU, şirket içi ağ erişimi veya imzalama anahtarı gibi ikamesi sınırlı bir havuzu topluca yenilemek işleri kuyrukta bırakabilir. Her kohort için eş zamanlı iş yükünü karşılayacak yeni kapasite hazır olmadan eski kapasiteyi azaltmayın.

Eski runner’ları iş kesmeden tahliye edin

1. Hedef runner paketini VM veya container imajına, kurulum betiğine ve dağıtım otomasyonuna birlikte alın. Bu kaynaktan küçük bir yeni kohort oluşturun.
2. Yeni runner’ları doğru kapsam, grup ve etiketlerle kaydedin. API envanterinde hedef version ve online durumunu görmeden eski kohortu küçültmeyin.
3. Yeni işleri yeni kohorta yönlendirin. Eski runner hâlâ workflow’un seçtiği etiketleri taşıyorsa yalnızca yeni bir bakım etiketi eklemek onu seçim dışı bırakmaz; grup erişimini veya workflow seçicisini kontrollü biçimde değiştirin.
4. Eski kohorta yeni iş atanmasını engelledikten sonra busy değeri false olana kadar bekleyin. Aktif işi kesmek yerine önceden belirlenmiş operasyon zaman aşımını ve eskalasyon yolunu uygulayın.
5. Boşalan kalıcı runner’ı durdurup yükseltin veya immutable havuzdaki eski örneği kaldırın. Aynı eski imajdan yeni örnek oluşturmayın.
6. Yeni kohort doğrulamayı geçtikçe kapasiteyi kademeli artırın. Kuyruk süresi, workflow başarısı veya gerekli araç zinciri bozulursa yayılımı durdurun.

busy alanı tek başına tahliye mekanizması değildir; yalnızca gözlem anındaki meşguliyeti gösterir. Eski runner’ın yeni bir iş kapmasını önleyen yönlendirme değişikliği ile bu alanı birlikte kullanın. Özellikle geniş kapsamlı self-hosted etiketine bağlı workflow’larda seçimi üretim bakımından önce sınayın.

İmaj yenileme ile otomatik güncellemeyi tek plana bağlayın

Kalıcı runner’larda otomatik güncellemeyi kullanıyorsanız güncelleme hizmetine ağ erişimini ve filoda oluşan sürüm dağılımını izleyin. Otomatik güncellemeyi kapatıyorsanız yeni sürüm algılama, paket doğrulama, imaj oluşturma, küçük kohort dağıtımı ve eski örnekleri tüketme adımlarının sahibi ve süresi belli olmalıdır.

Ephemeral veya immutable filoda çalışan örneği sonradan yamalamak yerine runner paketini kaynak imajda değiştirin. İmaj kimliğini hedef runner sürümüyle ilişkilendirin; böylece API’de görülen eski bir sürümün hangi şablondan üretildiğini bulabilir ve aynı şablonun yeniden eski kapasite yaratmasını engelleyebilirsiniz.

Sürümü ve gerçek iş kabiliyetini doğrulayın

Bir kohortu tamamlanmış saymadan önce API’de beklenen version, online durum, etiketler ve ephemeral değerini kontrol edin. Ardından üretimde gereken derleyici, container erişimi, ağ rotası ve kimlik doğrulama yolunu kullanan kontrollü bir workflow çalıştırın. Runner’ın çevrim içi görünmesi, bu bağımlılıkların çalıştığını tek başına göstermez.

Denetim günlüğünü envanterin yerine değil, değişiklik kanıtı olarak kullanın. Enterprise audit log olayları, enterprise.self_hosted_runner_updated kaydında runner kimliğiyle birlikte source_version ve target_version alanlarını tanımlar. Dağıtım kaydı, API envanteri ve workflow sonucu aynı kohortu gösterdiğinde güncellemeyi kapatın; sabit 2.329.0 kontrolü yerine hareketli çalışma desteğini düzenli olarak yeniden değerlendirin.

Ayrıca okuyun:

• İstisna belgesi yetmiyor: İçerik geliri tek banka hesabından geçmeli