- Katılım
- 21 May 2023
- Mesajlar
- 496
- Tepki
- 17
- Puan
- 18
Bir iş akışı yeşil tamamlanıyor ama testte eski paket, eski oluşturulmuş dosya veya dünün yapılandırması görünüyor. İlk tepki genellikle bütün önbellekleri silmek oluyor. Oysa eski dosya; checkout, bağımlılık önbelleği, derleme klasörü, Docker katmanı veya indirilen artifact gibi farklı bir yerden gelebilir.
Doğru teşhis için önce hangi dosyanın hangi adımda değiştiğini bulmak gerekir. Bu rehber özellikle GitHub Actions içindeki
Logun sonuna bakıp “cache bozuk” demeden önce aynı dosyayı üç noktada tanımlayın: checkout sonrası, cache restore sonrası ve kurulum/derleme sonrası. Commit kimliği, dosya yolu, boyut ve içerik özeti yan yana geldiğinde değişikliği hangi adımın geri aldığı görülür.
Bu değerler sır içermeyen dosyalarda kullanılmalı. Ortam dosyası, token veya özel anahtarı loga yazmayın. Cache edilen
GitHub'ın dependency caching referansına göre action önce verilen
Lock dosyası değiştiğinde ana anahtar da değişir. Geniş
Resmî actions/cache deposu,
Mevcut bir cache'in içeriği aynı anahtarla değiştirilemez. Sabit
Aynı görünen anahtarın yine de miss olması da mümkündür. Cache; anahtar, sürüm ve dal kapsamıyla aranır.
Bu yazı için GitHub hizmetine bağlanmayan, deterministik bir yerel arama modeli çalıştırıldı. İki farklı lock dosyasından
Model, doğrulama/kurulumdan sonra yeni içeriği yeni anahtarla kaydetti. Sonraki arama yeni anahtarda tam hit verdi; eski cache de değişmeden kaldı. Bu test resmî GitHub cache sunucusunu taklit ettiğini iddia etmez. Yalnızca dokümante edilen “yeni key miss + geniş restore prefix = eski başlangıç içeriği” mantığını tekrarlanabilir verilerle gösterir.
GitHub CLI cache listesi, anahtar, dal referansı, oluşturulma/son erişim zamanı ve cache sürümünü birlikte gösterebilir:
Logdaki gerçek anahtarı bu listeyle karşılaştırın. Sorun tek girdideyse hedefli anahtar değişikliği veya hedefli silme düşünün; ilk adım olarak bütün repository cache'ini temizlemeyin. Artifact'i de cache yerine koymayın: yayınlanacak binary veya test raporu, aynı run içinde açıkça üretilmeli ve artifact akışıyla saklanmalıdır.
Git temeli için dal ve commit rehberine, geçmişi güvenle düzeltmek için revert, reset ve reflog ayrımına, HTTP tarafındaki benzer isimli ama farklı katman için CDN cache teşhisine bakabilirsiniz.
Sizde eski dosya restore adımından hemen sonra mı, yoksa build tamamlandıktan sonra mı beliriyor? Gizli değerleri kapatarak yalnızca key, path, ref ve
Güncelleme: 16 Ağustos 2026. Resmî deponun güncel örnekleri actions/cache v6 kullanıyor. Self-hosted runner kullanıyorsanız yükseltmeden önce v6 için güncel README ve runner uyumluluk gereksinimlerini yeniden kontrol edin.
Doğru teşhis için önce hangi dosyanın hangi adımda değiştiğini bulmak gerekir. Bu rehber özellikle GitHub Actions içindeki
actions/cache davranışını ele alıyor; diğer cache katmanlarını aynı sepete atmıyor.Eski dosyanın ilk göründüğü adımı bulun
Logun sonuna bakıp “cache bozuk” demeden önce aynı dosyayı üç noktada tanımlayın: checkout sonrası, cache restore sonrası ve kurulum/derleme sonrası. Commit kimliği, dosya yolu, boyut ve içerik özeti yan yana geldiğinde değişikliği hangi adımın geri aldığı görülür.
Kod:
git rev-parse HEAD
sha256sum package-lock.json
sha256sum yol/aranan-dosyaBu değerler sır içermeyen dosyalarda kullanılmalı. Ortam dosyası, token veya özel anahtarı loga yazmayın. Cache edilen
path dışındaki bir dosya değişiyorsa sorun başka adımdadır.Ana anahtar ile geri yükleme anahtarını ayırın
GitHub'ın dependency caching referansına göre action önce verilen
key için tam eşleşme arar. Bulamazsa anahtar öneki ve sırayla restore-keys eşleşmeleri devreye girebilir. Birden çok kısmi eşleşme varsa en son oluşturulan cache geri yüklenir; bu, tanımlanan davranıştır.
Kod:
- id: npm-cache
uses: actions/cache@v6
with:
path: ~/.npm
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-npm-
- name: Bağımlılıkları doğrula ve kur
run: npm ciLock dosyası değiştiğinde ana anahtar da değişir. Geniş
Linux-npm- öneki, yeni anahtar henüz yoksa eski indirme önbelleğini başlangıç olarak getirebilir. Bu nedenle kısmi restore sonrası paket yöneticisinin doğrulama/kurulum adımı mutlaka çalışmalıdır.En sık mantık hatası' Alıntı:
Cache hit sonucunu doğru okuyun
Resmî actions/cache deposu,
cache-hit çıktısının ana key tam eşleştiğinde true olduğunu; restore-keys ile restore edildiğinde false döndüğünü belirtiyor. Hiç cache bulunmamasında ise değer boş olabilir. Bu üç durumu tek bir “var/yok” kontrolüne indirgemeyin.Mevcut bir cache'in içeriği aynı anahtarla değiştirilemez. Sabit
Linux-deps anahtarı kullanılıyorsa yeni içerik eski girdinin üzerine yazılmaz; yeni bir anahtar gerekir. Lock dosyası özeti yanında içeriği etkileyen araç sürümü veya elle artırılan cache-schema-v2 gibi bir bileşen kullanılabilir.Aynı görünen anahtarın yine de miss olması da mümkündür. Cache; anahtar, sürüm ve dal kapsamıyla aranır.
path veya sıkıştırma aracı değişince cache sürümü değişebilir. Arama önce mevcut dalda, gerekli durumda varsayılan dalda devam eder; kardeş dallardaki her cache evrensel olarak paylaşılmaz.Anahtarın gerçek girdilerini logda görün
hashFiles kalıbının repository'deki gerçek lock dosyasıyla eşleştiğini kontrol edin. Monorepo'da yalnızca kökteki lock dosyasını hash'lemek, alt paketteki değişikliği anahtara yansıtmayabilir. Tersine çok geniş bir glob, ilgisiz dosya değişikliğinde gereksiz cache miss üretebilir.- Path dar mı? Paket indirme klasörüyle eski build çıktısı aynı cache'e karışmasın.
- Araç sürümü etkili mi? Node, paket yöneticisi veya derleyici değişimi sonucu etkiliyorsa anahtarda temsil edin.
- Restore öneki fazla geniş mi? Farklı araç veya çıktı şemalarını aynı önekin altında toplamayın.
- Kurulum deterministik mi? Lock dosyasını uygulayan
npm cibenzeri komut cache içeriğini son gerçek kabul etmesin; doğrulayıp eksikleri tamamlasın.
Yerel model eski restore davranışını nasıl gösterdi?
Bu yazı için GitHub hizmetine bağlanmayan, deterministik bir yerel arama modeli çalıştırıldı. İki farklı lock dosyasından
Linux-deps-98c9c52b77f5 ve Linux-deps-391f6f66d32c anahtarları üretildi. Depoda yalnız ilk anahtar varken ikinci anahtar için tam hit bulunmadı; Linux-deps- öneki eski deps-v1 içeriğini getirdi ve sonuç cache-hit=false oldu.Model, doğrulama/kurulumdan sonra yeni içeriği yeni anahtarla kaydetti. Sonraki arama yeni anahtarda tam hit verdi; eski cache de değişmeden kaldı. Bu test resmî GitHub cache sunucusunu taklit ettiğini iddia etmez. Yalnızca dokümante edilen “yeni key miss + geniş restore prefix = eski başlangıç içeriği” mantığını tekrarlanabilir verilerle gösterir.
Cache listesini silmeden önce görün
GitHub CLI cache listesi, anahtar, dal referansı, oluşturulma/son erişim zamanı ve cache sürümünü birlikte gösterebilir:
Kod:
gh cache list --key Linux-npm- --ref refs/heads/main \
--json key,ref,createdAt,lastAccessedAt,versionLogdaki gerçek anahtarı bu listeyle karşılaştırın. Sorun tek girdideyse hedefli anahtar değişikliği veya hedefli silme düşünün; ilk adım olarak bütün repository cache'ini temizlemeyin. Artifact'i de cache yerine koymayın: yayınlanacak binary veya test raporu, aynı run içinde açıkça üretilmeli ve artifact akışıyla saklanmalıdır.
Git temeli için dal ve commit rehberine, geçmişi güvenle düzeltmek için revert, reset ve reflog ayrımına, HTTP tarafındaki benzer isimli ama farklı katman için CDN cache teşhisine bakabilirsiniz.
Sizde eski dosya restore adımından hemen sonra mı, yoksa build tamamlandıktan sonra mı beliriyor? Gizli değerleri kapatarak yalnızca key, path, ref ve
cache-hit sonucunu paylaşırsanız arama sırasını birlikte okuyabiliriz.Güncelleme: 16 Ağustos 2026. Resmî deponun güncel örnekleri actions/cache v6 kullanıyor. Self-hosted runner kullanıyorsanız yükseltmeden önce v6 için güncel README ve runner uyumluluk gereksinimlerini yeniden kontrol edin.
Dijital Dünyanıza Yön Veren Pusula
