GitHub Actions Ubuntu 26.04 Geçişi: Aynı Commit ile Runner Farklarını Tespit Etmek
Kaynak kodunu değiştirmemiş olsanız bile CI sonuçları farklılık gösterebilir. Çalıştırma ortamını ubuntu-latest etiketine bırakan bir iş akışında, işletim sistemi imajının geçişi de ekibin yönetmesi gereken değişiklikler arasında yer almalıdır.
GitHub, 17 Eylül 2026 tarihinde Ubuntu 26.04 runner'larının resmi desteğini ve ubuntu-latest geçiş planını duyurdu. Bu yazı, yeni imajın her halükarda daha hızlı olduğunu iddia eden bir tanıtım değil; aynı commit ile ortam farklarını ayrıştırarak doğrulamaya yönelik pratik bir öneridir.
Resmi Duyurudan Doğrulanan Kapsam
Duyuruya göre Ubuntu 26.04 imajı x64 ve arm64 üzerinde resmi olarak desteklenmekte olup açık etiketleri ubuntu-26.04 ve ubuntu-26.04-arm şeklindedir. ubuntu-latest etiketi, 19 Ekim 2026 ile 19 Kasım 2026 tarihleri arasında kademeli olarak Ubuntu 24.04'ten 26.04'e taşınacaktır.
Yeni imajda güncellenen veya kaldırılan araçlar bulunduğundan, önceden yüklenmiş paketlere bağımlı derlemeler etkilenebilir. Hazırlıklarınız tamamlanmadıysa GitHub, etiketi ubuntu-24.04 olarak açıkça belirtme yöntemini önermektedir. Bu takvim, her bir deponun fiili geçiş tarihini doğrudan ifade etmez.
Depomuzun Beklediği Ortamı Belgelemek
Öncelikle iş akışlarınızda ve yeniden kullanılabilir iş akışlarında runs-on değerini kontrol edin. Yalnızca bir kapsayıcı (container) kullanıyor olmanın ana makine (host) etkilerini tamamen ortadan kaldırdığını varsaymayın; kapsayıcı dışında çalışan kurulum, sıkıştırma ve karşıya yükleme adımlarını da incelemek faydalıdır.
Kontrol listenize derleyicileri, çalışma zamanlarını (runtime), paket yöneticilerini ve sistem kütüphanelerini ayrı ayrı not edin. Yalnızca araç adını yazmak yerine, nereden yüklendiğini ve hangi adımın onu çağırdığını ilişkilendirirseniz hata günlüklerindeki asıl sebebi daraltmak çok daha kolaylaşır.
Aynı Commit, İki Ortam, Bağımsız Çıktılar
Geçiş denemesine dağıtım yetkisi bulunmayan bir test kanalında başlamak süreci daha net kılar. Aynı commit ve kilit dosyasını (lockfile) hem mevcut hem de yeni imajda çalıştırarak günlükleri, test sonuçlarını ve çıktı adlarını ayrı ayrı saklayın. Bu, bu makalede önerilen doğrulama yöntemidir.
İlk karşılaştırmalarda eski önbelleğin (cache) etkisini ayırt edebilmek için önbellek koşullarını kaydedin. Yalnızca derlemenin başarılı olup olmadığına değil, yüklenen araç sürümlerine, başarısız olan adımlara ve çıktıların çalışma sonuçlarına da yer vermelisiniz; böylece önbellek isabeti sayesinde tesadüfen geçen sonuçları ayırt edebilirsiniz.
Yeşil Onay İşaretinin Ardında Kalan Doğrulama
Bir web projesiyse oluşturulan dosyaların gerçekten sunulup sunulamayacağını, yerel (native) bağımlılıklar varsa hedef ortamda yüklenip yüklenemediğini kontrol edebilirsiniz. Tüm çıktıların bayt düzeyinde mutlaka aynı olması gerektiği kuralı yerine, zaman damgası gibi belirlenimci olmayan (non-deterministic) farklar ile işlevsel farkları birbirinden ayırarak değerlendirin.
İncelemeyi yapacak kişi; yeni imajın çalıştırma bağlantısını, araç sürümü farklarını, temel işlev testi sonuçlarını ve geri alınacak değişiklikleri tek bir yerde görebilmelidir. Runner geçişine uygulama refactoring işlemlerini de dahil etmek, hata kaynağını ve geri alma kapsamını gereksiz yere genişletir.
İmajı Sabitlemenin Avantajları ve Baki Kalan Sınırlar
Açık bir işletim sistemi etiketi kullanmak büyük geçişleri kontrol altında tutmaya yardımcı olur; ancak tamamen değişmez bir derleme ortamı anlamına gelmez. Çalıştırma için gereken araçları açıkça yükleme ve gerçek sürümleri günlüğe kaydetme alışkanlığını korumaya devam edin.
Küçük bir depoda devasa bir doğrulama sistemi kurmanıza gerek yoktur. Birincil bir derleme ve en hassas bağımlılıklarla karşılaştırmaya başlayabilir; geçici bir sabitleme yaptıysanız kilidi kaldırma sorumlusunu ve tekrar gözden geçirme tarihini not ederek yola çıkabilirsiniz.
Genel Tartışmalar ile Ekip Kararlarını Birbirinden Ayırmak
runner-images açık sorunlar (issues) alanı, imaj değişikliklerini ve sorun bildirimlerini takip etmek için uygun bir kanaldır. Belirli bir yorum veya başka bir projedeki başarısızlık, aynı durumun sizin deponuzda da tekrarlanacağı anlamına gelmez; bu yazı topluluk uzlaşısı veya arıza sıklığına dair sayısal bir iddiada bulunmaz.
Bugün yapılması gereken, latest etiketinin nerelerde kullanıldığını tespit etmek ve aynı commit'i yeni imajda test etmektir. Geçme ve bekletme koşullarını önceden belirlerseniz, asıl geçiş sürecinde derleme sonuçları değişse bile sorumlu kişi aynı somut kanıtlara dayanarak karar verebilir.