Nx 23 bucket cache eklentilerini kaldırdı: self-hosted HTTP cache'e geçmeden önce bilmeniz gerekenler

Neler değişti

Nx, özel bir remote cache bağlamanın eski yollarını kaldırdı. tasksRunnerOptions üzerinden yapılandırılan özel task runner'lar Nx 21 itibarıyla çalışmayı bıraktı ve Mayıs 2026'da Nx, kendi bucket eklentilerini — @nx/s3-cache, @nx/gcs-cache, @nx/azure-cache ve @nx/shared-fs-cache — kullanımdan kaldırdı; bu bilgiyi, hosted bir cache sağlayıcısı olan Cachely ekibinin dev.io'daki yazısından öğrendik. Kullanımdan kaldırma, CREEP (CVE-2025-36852) ile bağlantılı; bu, bir pull request derlemesinin, main branch derlemesinin daha sonra geri yükleyeceği artifact'lerin üzerine yazabildiği bir cache-poisoning açığı.

Nx Cloud kullanmak istemeyen ekipler için onaylanan çözüm, Nx 20.8'de tanıtılan self-hosted HTTP remote cache. İki environment değişkeni gerektiriyor — NX_SELF_HOSTED_REMOTE_CACHE_SERVER ve NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN — ve Nx'ün yayımladığı OpenAPI spesifikasyonunu uygulayan herhangi bir sunucu.

Cachely ekibi bu kurulumu Nx 23.2.1 üzerinde test etti ve ekiplerin geçiş yapmadan önce anlaması gereken dört davranışı raporladı.

.nx/cache klasörünü CI çalıştırmaları arasında kopylamak artık işe yaramıyor

Yaygın ve ücretsiz bir çözüm, .nx/cache dizinini GitHub'ın actions/cache veya Azure'ın Cache@2 ile CI çalıştırmaları arasında kalıcı kılmaktı; NX_REJECT_UNKNOWN_LOCAL_CACHE=0 ile birlikte kullanılıyordu. Bu numara artık ölü. Veritabanı destekli cache Nx 20'de varsayılan — ve Nx 21'de tek seçenek — olduğundan beri Nx, eşleşen metadata'ya da sahip olmadığı sürece artifact'leri geri yüklemeyi reddediyor; bu metadata ise .nx/cache içinde yaşamıyor. Klasörü temiz bir runner'a geri yüklemek tanınmayan-artifact uyarısı ve sıfır cache isabeti üretiyor ve NX_REJECT_UNKNOWN_LOCAL_CACHE ayarı yok sayılıyor.

Erişilemeyen bir cache sunucusu derlemeyi başarısız kılıyor

NX_SELF_HOSTED_REMOTE_CACHE_SERVER'daki URL kapalı bir porta işaret ediyorsa, Nx 1 durum koduyla çıkıyor ve görev daha başlamadan /v1/cache uç noktasına yapılan başarısız isteği raporluyor. Cache sunucusunun her zaman erişilebilir olacağının garanti olmadığı ekipler önce onu yoklamalı: yazı, cache uç noktasına kısa timeout'lü bir HTTP isteği yapmayı, hiçbir HTTP durum kodu dönmezse NX_SKIP_REMOTE_CACHE=true ayarlayarak local cache'e geri düşmeyi öneriyor. Kasıtlı olarak geçersiz bir hash için 404 dahil herhangi bir durum kodu, sunucunun ayakta olduğunu gösterir. Yazarlar, yalnızca bir çalıştırmanın başında kapalı olan bir sunucuyu test ettiklerini, çalışma ortasında ölen bir sunucuyu test etmediklerini belirtiyor.

Skip bayrakları birbirinin yerine kullanılamaz

Benzer isimli iki bayrak farklı şeyler yapıyor. Nx 20.5'ten beri mevcut olan --skip-remote-cache veya NX_SKIP_REMOTE_CACHE=true yalnızca remote cache'i devre dışı bırakıyor; Nx remote caching'in kapalı olduğunu duyuruyor ama local cache'e danışmaya devam ediyor. --skip-nx-cache veya NX_SKIP_NX_CACHE=true ise hem local hem remote cache'i atlıyor ve her şeyi yeniden çalıştırıyor. Ayrıca nx reset yalnızca local cache'i temizler — Nx CLI'daki hiçbir şey bir remote sunucudaki girdileri silmez, dolayısıyla sunucu tarafındaki cache ömrü operatörün sorunudur.

Sunucu üzerine yazmayı reddetmeli

Self-hosted API yüzeyi minimal: /v1/cache/{hash} üzerinde GET ve PUT. Önemli olan, çakışma durumunda PUT'un nasıl davrandığı. Uyumlu bir sunucu, mevcut bir hash'i hedefleyen PUT için 409, read-only token için 403 döndürmelidir. Bu değişmezlik, CREEP'in asıl çözümüdür: bir pull request derlemesinin, daha sonraki bir main derlemesinin güveneceği bir artifact'in yerine geçmesini engeller. Yazının yazarları, kendi sunucusunu çalıştıran herkese, ona güvenmeden önce hem 409 hem 403 yollarını test etmesini öneriyor. Nx, uyumlu bir sunucu oluşturmanın tam spesifikasyonunu self-hosted caching rehberinde belgeliyor.

Neden önemli

Bu, kaldırma yoluyla değil kullanımdan kaldırma yoluyla gelen bir breaking change; bu da bir pipeline yavaşlayana veya bir eklenti çalışmayı durdurana kadar gözden kaçması kolaylaşıyor. Şu anda CI'da .nx/cache'i kalıcı kılan ekipler, veritabanı cache'i metadata'sı olmayan geri yüklenmiş dosyaları yok saydığı için, zaten sessizce tüm remote-cache avantajlarını kaybediyor. Göçün ötesinde, güvenlik modeli de değişti: doğrululuk artık cache sunucusunun değişmezliği zorunlu kılmasına bağlı, dolayısıyla self-hosting bu garantinin sahibi olmak demek. Kaynak yazının Cachely tarafından yazıldığını, Cachely'nin bu spesifikasyonun hosted bir uygulamasını sattığını ve dolayısıyla ekiplerin göç etmesinde ticari çıkarı olduğunu unutmayın — Nx davranışına ilişkin teknik iddialar bağımsız olarak test edilebilir, ancak çerçeveleme tarafsız değil.