CloudX, Go CI test çalışma sürelerini %69 kısaltan setup-go alternatifini open source yaptı

Ne oldu

Paralel Go lint, test ve build job'larıyla çalışan bir web monorepo'ya sahip şirket CloudX, cloudx-io/setup-go adlı bir GitHub Action'ı open source yaptı. Hacker News'in ana sayfasına çıkan bir CloudX blog yazısına göre bu action, GitHub'ın resmi actions/setup-go'sunun yerini birebir alabiliyor ve şirket bunun yerine takılması, Go test job'larının çalışma sürelerini %69 kısalttı.

Depolarına karşı yapılan geriye dönük testlerde CloudX, varsayılan action'ın cache kurulumu altında yapılan işin yaklaşık %86'sının gereksiz olduğunu tahmin ediyor. Şirket bu değişikliği daha geniş bir mühendislik çabasının parçası olarak sunuyor: amacı, mühendislere bir push'tan sonra 90 saniye içinde kesin bir build-ve-test sonucu vermek ve CI'yı zaten Warp Build makinelerinde çalıştırıyor.

actions/setup-go'nun cache'i nerede yanlış çalışıyor

Resmi action, Go'nun modül ve build cache'lerini çalıştırmalar arasında actions/cache ile kalıcı hale getiriyor. CloudX'un tespit ettiği zayıf nokta, işletim sistemi, CPU mimarisi, Go sürümü ve go.mod içeriği gibi girdilerden türetilen cache anahtarı. Aktif geliştirilen bir kod tabanında neredeyse hiçbir değişiklik bunlara dokunmaz.

Çalışan ilk job bu anahtarı hesaplar ve nihai cache durumunu GitHub'ın cache servisine kaydeder. Anahtar nadiren değiştiği için, sonraki her çalıştırma aynı özgün anlık görüntüyü geri yükler. Kod tabanı ilerledikçe geri yüklenen build arşivleri ve test sonuçları daha eski koda karşılık gelir; böylece her build daha çok işi sıfırdan yapar ve her çalıştırma daha çok testi yeniden yürütür. CloudX, performansın sonunda bir go.mod değişikliği anahtarı döndürene kadar kötüleştiğini söylüyor.

Paralel job'lar durumu daha da kötüleştirir. Ayrı lint ve test job'ları aynı varsayılan anahtarı çözer ve sonra onu yazmak için yarışır. GitHub'ın cache girdileri bir kez yazıldıktan sonra değiştirilemez, bu yüzden yalnızca ilk yazan kazanır: lint job'ı önce biterse, kaydedilen değer güncel test sonuçlarını içermez ve sonraki test job'ları bayat değeri geri yüklemeye ve testleri yeniden çalıştırmaya devam eder.

Go bunu zaten çözüyor — cache hayatta kalırsa

CloudX'un argümanı, Go toolchain'inin kendisinin mükemmel bir memoizer olduğudur. Modül cache'i (GOMODCACHE) indirilen bağımlılık kaynaklarını saklarken, build ve test cache'leri Linux'ta ~/.cache/go-build konumunda bulunan GOCACHE dizinini paylaşır. Build ve test süreçleri tüm girdilerini hash'ler ve yeniden kullanılabilir çıktılar saklar: build'ler için paket arşivleri, testler için ise yakalanan stdout, stderr ve çıkış kodları. Test koşucusu ayrıca bir testin hangi dosyaları okuduğunu izler ve içeriklerini hash'e katıp sonuçların yalnızca girdileri gerçekten değişmediğinde yeniden kullanılmasını sağlar.

Bu tasarım kalıcı bir dosya sisteminde çalışır. Geçici CI runner'larında böyle bir şey yoktur, bu yüzden bu toolchain cache'leri çalıştırmalar arasında GitHub'ın cache servisi üzerinden taşınmak zorundadır; bu servis ise yalnızca job başarılıysa, yalnızca birincil anahtar kaçırıldıysa kaydeden ve mevcut bir girdiyi asla üzerine yazmayan daha basit bir anahtar-ve-yol deposudur. İki cache katmanı arasındaki bu uyumsuzluk, isabet oranlarının çöktüğü yerdir.

Alternatif neleri değiştiriyor

CloudX'un action'ı resmi olanla aynı kullanıma sahip ama cache stratejisini, Go'nun yerel cache'lerinin paralel job'lar arasında etkili kalmasını sağlayacak şekilde yeniden düşünüyor. Şirket, bilinçli olarak tekrarlanan kurulum işini ve daha yüksek cache depolama maliyetlerini kabul ettiklerini söylüyor: paralelleştirilebilir iş, faturalandırılan runner süresini artırsa bile paralel çalışmalıdır ve cache alanı için ayda birkaç ekstra dolar, engellenmiş mühendislerden ve coding agent'lerden daha ucuzdur. CloudX'a göre temel içgörü şudur: Go toolchain'inin cache'lemesi zaten çok iyidir ve CI katmanının görevi bunu baltalamamaktır.

Neden önemli

GitHub Actions'ta birden çok Go job'ı çalıştıran herhangi bir ekip için bu düşük maliyetli bir deneydir: tek bir action referansını değiştirin ve ölçün. CloudX, orta düzey karmaşıklıktaki Go projeleri için benzer kazanımların elde edilebileceğini iddia ediyor; ancak öne çıkan rakamlar tek bir şirketin monorepo'sundan geliyor ve çok hızlı testleri ya da basit build'leri olan iş yükleri daha az fayda görecektir.

Daha geniş bir bakışla, bu yazı geçici CI altyapısında cache anahtarı tasarımına dair yararlı bir vaka çalışması. GitHub'ın cache değişmezliği ve bir kez kaydetme semantiği tek başına değerlendirildiğinde makuldür; ancak kaba anahtarlarla birleştiğinde, Go gibi bir toolchain'in sağladığı sofistike cache'lemeyi sessizce etkisiz hale getirebilir. Daha hızlı CI bileşik etki yaratır: daha kısa geri bildirim döngüleri hem mühendisleri hem de coding agent'leri bloke olmaktan korur — CloudX'un ödediği paranın tam olarak satın almak istediği sonuç da bu.