GitHub Actions geçmişinde 1 Ekim saklama değişikliği

GitHub, 1 Ekim 2026’dan itibaren checks, workflow runs ve statuses kayıtlarını, artifact ve loglar için kullanılan mevcut Actions saklama ayarına bağlayacak. GitHub’ın 27 Ağustos duyurusuna göre varsayılan süre 90 gün olacak ve yapılandırılmış süreyi aşan kayıtlar otomatik olarak temizlenecek.

Değişiklik henüz yürürlükte değil; belirlenen uygulama tarihi 1 Ekim 2026. Mevcut ayarı 90 gün olan bir depoda bu tarihten sonra daha eski check, workflow run ve status geçmişi GitHub’dan silinebilecek. Bu üç kayıt türü şimdiye kadar saklama ayarından bağımsız biçimde 400 günden uzun süre tutuluyordu.

1 Ekim’de hangi kayıtların saklama biçimi değişecek?

GitHub Actions içindeki beş kayıt türünün ortak saklama süresine bağlanması

Politika değişikliği beş kayıt türünün aynı süreyi izlemesi sonucunu doğuracak. Artifact ve loglar zaten mevcut ayara tabiydi; yeni kapsama checks, workflow runs ve statuses eklenecek.

Checks: Commit veya pull request üzerinde görülen kontrol çalışmaları ve sonuçları.
Workflow runs: İş akışlarının çalıştırma geçmişi, sonucu ve çalıştırmayla ilişkili bilgiler.
Statuses: Commit’lere bağlanan başarı, hata veya bekleme durumları.
Artifacts: İş akışlarının GitHub’a yüklediği derleme paketleri, test raporları ve diğer dosyalar.
Logs: Job ve adımlar çalışırken üretilen yürütme kayıtları.

GitHub, arayüzdeki ayar etiketini de beş türü kapsayacak biçimde “Check, workflow run, status, artifact and log retention” olarak değiştirecek. Buradaki önemli ayrım, workflow run kaydı ile ona bağlı log ve artifact dosyalarının farklı veri türleri olmasıdır; ortak süreye tabi olmaları hepsinin aynı içerikten oluştuğu anlamına gelmez.

Varsayılan süre ve depo sınırları ne olacak?

Açık ve özel GitHub depolarındaki saklama sınırlarının üst politikalarla karşılaştırılması

Varsayılan değer 90 gün, ancak seçilebilecek aralık depo görünürlüğüne ve üst düzey politikalara göre değişiyor. Güncel bağımsız inceleme, açık depolarda 1–90 gün, özel ve internal depolarda ise üst politikalar izin verdiğinde 1–400 gün aralığını doğruluyor.

Açık depo: Varsayılan 90 gün; en fazla 90 gün.
Özel veya internal depo: Varsayılan 90 gün; kuruluş ve enterprise sınırları izin veriyorsa en fazla 400 gün.
Yönetilen depo veya kuruluş: Seçilen süre, yöneten kuruluşun ya da enterprise hesabının belirlediği tavanı aşamaz.

Dolayısıyla yalnızca depo düzeyindeki değere bakmak etkili saklama süresini her zaman göstermez. Enterprise politikası kuruluşu, kuruluş politikası da depoyu sınırlayabilir. Sürenin daha sonra artırılması, önceki saklama politikası nedeniyle zaten kaldırılmış kayıtları geri getirmez.

Ayar arayüzden ve REST API’den nasıl kontrol edilir?

GitHub Actions saklama ayarının kuruluş arayüzü ve REST API üzerinden kontrol edilmesi

Kuruluş sahibi, kuruluş sayfasında Settings bölümünü açıp Actions ve ardından General yolunu izleyerek saklama değerini görebilir. Girilen gün sayısı, varsa enterprise düzeyindeki üst sınırın altında kalmalıdır. Depo ve enterprise düzeylerinde de etkili değeri sınırlayan ilgili Actions ayarları ayrıca kontrol edilmelidir.

Çok sayıda kuruluşu yöneten ekipler aynı politikayı REST API ile okuyabilir veya değiştirebilir. GitHub’ın Actions permissions API belgesi, GET ve PUT /orgs/{org}/actions/permissions/artifact-and-log-retention uç noktalarını tanımlıyor; yeni süre PUT gövdesindeki days alanıyla gönderiliyor. Fine-grained token kullanıldığında okuma için kuruluş düzeyinde Administration read, değiştirme için Administration write izni gerekiyor.

Bu uç noktalar yalnızca saklama politikasını yönetir. Workflow run geçmişini, logları veya artifact dosyalarını harici depoya aktaran bir yedekleme işlevi sunmaz. GitHub’daki süreden daha uzun süre tutulması gereken kayıtlar için ayrıca dışa aktarma ve arşivleme düzeni gerekir.

Olay incelemesi, denetim ve maliyet aynı şekilde etkilenmeyecek

Olay ve hata incelemesinde kayıp, eski çalıştırmanın GitHub içindeki bağlamına erişilememesidir. Bir ekip 90 günden eski bir dağıtımı araştırırken run sonucu, ilgili check ve commit status kaydı saklama penceresinin dışında kalabilir. Kaynak commit’in Git geçmişinde bulunması, çalıştırma logunun veya üretilen artifact dosyasının da korunduğunu göstermez.

Denetim ve uyumlulukta süreyi artırmak tek başına eksiksiz kanıt oluşturmaz. Commit kimliği, kullanılan workflow sürümü, çalıştırmayı başlatan olay, sonuç, onay kaydı ve artifact bütünlük bilgisi farklı yerlerde bulunabilir. Kurumsal saklama zorunluluğu GitHub’daki etkili süreyi aşıyorsa gerekli metadata, log ve artifact dosyalarının bağlantıları korunarak kontrollü bir harici arşive aktarılması gerekir.

Maliyet tarafında ise metadata ile dosya depolaması ayrılıyor. Checks, workflow runs ve statuses metadatası Actions depolaması için ayrıca faturalandırılmıyor; bunlarla ilişkili artifact ve loglar faturalandırılabilir depolamaya dahil oluyor. Ortak süreyi yükseltmek geçmişi daha uzun erişilebilir tutabilir, fakat log ve artifact dosyalarının da daha geç silinmesi nedeniyle depolama kullanımını artırabilir.

1 Ekim’de mevcut ayar otomatik uygulanacak

GitHub çoğu depo için zorunlu bir yapılandırma değişikliği istemiyor. 1 Ekim 2026’da checks, workflow runs ve statuses, o anda depo, kuruluş veya enterprise için geçerli olan saklama değerine göre temizlenmeye başlayacak.

Bu nedenle 90 günden uzun çevrim içi geçmişe ihtiyaç duyan özel ve internal depo ekipleri etkili üst sınırı uygulama tarihinden önce belirlemeli. Açık depolarda 90 günlük tavan değişmediği için daha uzun denetim geçmişi GitHub’daki ayarla korunamayacak; sürenin ötesinde gerekli kayıtların silinmeden önce dışarı aktarılması gerekecek.

Ayrıca okuyun:

GitHub Actions geçmişi 90 günde silinebilir: son tarih 1 Ekim