GitHub Actions cache-mode: Yeşil CI'ın Ardındaki Önbellek İzinlerini Doğrulama
CI yeşil yandığı hâlde bir sonraki çalıştırmada bağımlılıklar yeniden indiriliyorsa, ilk akla gelen önbellek anahtarını düzeltmek olur. Artık izinler nedeniyle kaydetme işleminin atlanıp atlanmadığını da kontrol etmelisiniz. Çünkü iş akışının başarılı olması tek başına önbelleğin oluşturulduğunu kanıtlamaz.
GitHub, 10 Eylül 2026 tarihinde cache-mode özelliğinin genel erişime açıldığını duyurdu. github.com üzerindeki tüm planlarda önbellek erişimini iş akışı veya iş (job) düzeyinde belirleyebilirsiniz. Salt okunur varsayılan ayarı ele alan önceki yazının bir adım ötesine geçerek bu kez açık yapılandırma ve doğrulama yöntemlerine odaklanıyoruz.
Doğrulanmış Özellikler: Geri Yükleme ve Kaydetmenin Dört Kombinasyonu
read yalnızca geri yüklemeye, write ise hem geri yükleme hem de kaydetmeye izin verir. write-only yalnızca kaydetmeye izin verirken, none her ikisini de engeller. İlk kontrol, write adını yalnızca kaydetme olarak yanlış anlamamaktır.
Bir işte tanımlanan değer, iş akışı düzeyindeki ayarın önüne geçer. Buna karşılık, yeniden kullanılabilir bir iş akışı çağrısında, çağıran tarafın izin verdiğinden daha yüksek bir erişim yetkisi elde edilemez. Yalnızca tek bir dosyadaki bildirime bakarak çalıştırmanın tamamındaki gerçek izinleri değerlendirmeyin.
Yeşil Çalıştırma Bile Kaydedildiğinin Kanıtı Değildir
Resmî belgeler, izin verilmeyen önbellek işlemlerinin bilgilendirme günlüğü bırakarak devam ettiğini açıklar. Engellenen bir geri yükleme önbellek ıskalaması (cache miss) olarak kabul edilir ve engellenen bir kaydetme işlemi yürütülmez. Gözlem açısından en kritik nokta, iş akışının kendisinin başarısız olmamasıdır.
Bu nedenle operasyon kayıtlarını çalıştırma başarısı ve önbellek sonucu olarak ikiye ayırmak faydalıdır. Hangi olayın tetiklendiğini, hangi modun uygulandığını, geri yükleme yapılıp yapılmadığını ve kaydetmenin atlanıp atlanmadığını tek bir çalıştırmada inceleyin. Bu yaklaşım, resmî özellik açıklamalarına dayalı bir operasyonel öneridir; otomatik olarak sunulan yeni bir gösterge paneli işlevi değildir.
Uygulamadan Önce Küçük Bir İzin Tablosu Hazırlayın
Deponuzun gerçek iş akışlarını inceleyerek önbellek üreten ve tüketen işleri tespit edin. Güvenilir bir dalda bağımlılıkları hazırlayan bir işi, harici değişiklikleri test eden bir işi ve dağıtım çıktılarını doğrulayan bir işi aynı izinler altında toplamak zorunda değilsiniz.
Her iş için şu iki soruyu yanıtlayın: Bu işin mevcut önbelleği okuması gerekiyor mu? Bu işin sonucunun bir sonraki çalıştırma tarafından okunmasına izin verilmeli mi? İkisine de ihtiyaç yoksa önbellek ekleme alışkanlığınızı gözden geçirebilirsiniz. Ancak gerçek yapılandırma, deponun güven sınırlarına ve derleme yapısına göre belirlenmelidir.
En Küçük Deney: Salt Okunur Tüketim İşi
Örneğin, bir test iş akışının en üst düzeyinde cache-mode: read belirterek iş düzeyinde geçersiz kılma bulunmadığından emin olun. Önbellek kullanıldığındaki test sonuçları ile önbellek bulunmadığı durumdaki sonuçları karşılaştırın. Önbellek, yürütme süresini kısaltan yardımcı bir araç olmalıdır; önbelleğin yokluğunda doğruluk değişiyorsa öncelikle derleme varsayımlarını kontrol etmelisiniz.
Bu deneyin başarı ölçütü CI'ın başarıyla tamamlandığını gösteren tek bir satır değildir. Geri yükleme girişimini ve kaydetmenin atlanışını açıklayabilmeli, sonraki çalıştırmada aynı girdilerle yeniden doğrulayabilmelisiniz. Deney öncesi ve sonrası commit'leri, tetikleyicileri, geçerli ayarları ve günlük konumlarını birlikte kaydetmek, ekip arkadaşlarınızın da bu kararı kolayca yeniden üretmesini sağlar.
Yeniden Kullanılabilir İş Akışlarında Çağrı Yolunu İnceleyin
Ortak iş akışına güvenli varsayılanlar yerleştirilmiş olsa bile çağıran tarafı ve bireysel iş ayarlarını birlikte gözden geçirmelisiniz. Farklı depoların aynı dosyayı çağırması, aynı izinlerle çalıştıkları anlamına gelmez.
İnceleme sırasında çağıran taraftan başlayarak işin önbellek bildirimini ve çağrılan iş akışını sırayla takip edin. Beklenen izinler ile gerçek günlükler uyuşmuyorsa, anahtarı daha karmaşık hâle getirmeden önce ayarın kaynağını bulun. Bu, yeniden kullanımın yoğun olduğu organizasyonlarda tanılama süresini kısaltmaya yönelik bir öneridir; ölçülmüş bir performans artışı iddiası taşımaz.
Dikkat Edilmesi Gereken İstisnalar ve Uygulama Sırası
pull_request_target gibi düşük güvenilirlikli etkinliklerde write veya write-only belirtmek, salt okunur varsayılan sınırlamasını geçersiz kılabilir ve önbellek kirlenmesi riskini artırabilir. GitHub bu durumda bir uyarı notu ekler. Uyarıyı ortadan kaldırmak için yazma izinlerini artırmak gibi bir yaklaşımdan kaçınılmalıdır.
Öte yandan tüm önbellekleri engellemenin de bir maliyeti vardır. İndirme ve derleme süreleri uzayabileceğinden, kapsamı genişletmeden önce temsili bir işte çalıştırma sürelerini doğrudan karşılaştırın. Rakamları tahmin ederek kesin performans vaatlerinde bulunmak yerine, güvenlik açısından gerekli kısıtlamaları ve kabul edilebilir gecikmeleri ekiple birlikte kararlaştırmak daha sağlıklıdır.
Ekibin Şimdi Yanıtlaması Gereken Sorular
Bugün yapılması gereken, yeni ayarları tüm depolara toptan eklemek değildir. Önemli bir iş akışında önbellek üreticilerini ve tüketicilerini bulup izinleri belirlemek, tek bir çalıştırmada geri yükleme ve kaydetme kanıtlarını doğrulamaktır. Söz konusu bir dağıtım işi ise sorumlunun günlükleri okuyup beklentilerle uyuştuğunu inceleyebilmesi için değişiklikleri küçük tutun.
Uygulamada ortaya çıkabilecek asıl soru, kaydetme adımı atlandığı hâlde CI'ın neden başarılı olduğudur. Bu yazı, söz konusu kafa karışıklığını resmî davranışlara dayanarak açıklamaktadır; bağımsız bir topluluk anketine ya da genel bir hata oranına dayanmaz. Yeni özelliği devreye alırken performans sonuçlarını ve izin sonuçlarını ayrı ayrı kontrol etmek, bir sonraki önbellek sorununu daha doğru sınıflandırmanızı sağlayacaktır.