Garnix kapatılıyor
(discourse.nixos.org)- garnix, Shopify ile birleşme sürecinin bir parçası olarak barındırma hizmetini 15 Temmuz 2026'da sonlandıracak
- garnix kod tabanı açık kaynak olarak yayımlanacak; böylece kullanıcılar kendi instance'larına veya paylaşılan bir instance'a geçebilecek
- Genel kullanıma açık bir topluluk instance'ı işletmekle ilgilenen kullanıcılar garnix ekibiyle iletişime geçebilir; ekip de bu konuda görüşmek istiyor
- 15 Temmuz 2026'da tüm kullanıcı verileri silinecek ve buna build çıktıları da dahil olacak
- Saklanması gereken veri ve build çıktıları kapanış tarihinden önce kullanıcılar tarafından doğrudan indirilmek zorunda; mevcut duyuru ise e-postadan alıntı biçiminde paylaşıldı
Hizmetin sona ermesi ve kodun açılması
- garnix, Shopify ile birleşiyor ve bu geçişin bir parçası olarak barındırılan garnix hizmetini 15 Temmuz 2026'da sonlandırıyor
- garnix kod tabanı açık kaynak olarak yayımlanacak; böylece kullanıcılar kendi instance'larına veya paylaşılan bir instance'a taşınabilecek
- Herkese açık bir topluluk instance'ı işletmekle ilgilenen kullanıcılar garnix ekibiyle iletişime geçebilir
Kullanıcı verileri ve geçiş hazırlığı
- 15 Temmuz 2026'da tüm kullanıcı verileri silinecek; buna build çıktıları da dahil
- Saklanacak veri veya build çıktıları varsa, bunlar kapanış tarihinden önce doğrudan indirilmek zorunda
- Kapanış duyurusu garnix.io üzerinde doğrulanmadı; içerik, contact@garnix.io adresinden alınan bir e-postadan alıntı olarak paylaşıldı
- garnix ekibi, Open Collective dönemindeki bağışlar ve geri bildirimler dahil topluluk desteği için teşekkür etti; ekip üyeleri Alex David, Sönke Hahn ve Julian K. Arni olarak belirtildi
1 yorum
Lobste.rs görüşleri
Üzücü! Rolling deployment sorununu çözmek için servis bağımlılığı URL'lerini servis build'ine gömen yazıyı gerçekten çok sevmiştim
https://garnix.io/blog/call-by-hash/
Garnix'in ne olduğunu merak edenler için:
Garnix, Nix'leştirilmiş flake tabanlı GitHub depoları için bir CI hizmeti
Kaynak: https://github.com/garnix-io/garnix-ci#garnix
Garnix, şimdiye kadar kullandığım CI sistemleri arasında açık ara en iyisiydi
GitHub Actions daha runner bulmaya çalışırken Garnix build'i çoktan bitirmiş oluyordu ve orta düzeyde karmaşık Rust projem bile genelde 1 dakika içinde tamamlanıyordu
Sadece dokümantasyonu değiştirdiğimde daha da hızlıydı ve dokümantasyonu gerçekten build ediyordu
Tabii bunda Nix'in payı büyük ama Garnix bu entegrasyonu gerçekten çok iyi yapmıştı
Build sistemiyle entegre bir CI, her seferinde S3'ten dosya sisteminin yarısı kadar bir tar indirip üstüne cache eklemeye çalışan yaklaşımdan çok daha iyi çalışabiliyor
Üstelik Nix tabanlı olduğu için lokalde build ettiğiniz şeyin aynısını build ediyor; bu da “yaml yazım hatasını düzelt, push et, 10 dakika bekle, bir sonraki hatayı gör, debug çıktısı ekle, tekrar push et...” gibi uzun geri bildirim döngülerini ortadan kaldırıyor
Lokalde build oluyorsa CI'da da çalışıyor
Yazık olmuş. Geçen hafta civarında birkaç tuhaf sorun görmüştüm ama çok da önemsememiştim
Sadece GitHub'ı desteklemesi biraz can sıkıcıydı ama yine de harika bir hizmetti
Hafta sonu açık kaynak sürümüne bakıp self-hosting'in gerçekçi olup olmadığına karar vermeyi düşünüyorum; Nix build için alternatifleri olan varsa duymak isterim
Çıktığı günden beri garnix kullanıyordum, kapanıyor olması gerçekten üzücü
Nix CI veya self-host edilebilen çözümler bilen varsa paylaşsa harika olur
Garnix'i çoğunlukla cache olarak kullanıyordum ve herkese açık check durumuna dayalı bir otomatik merge workflow'u da kurmuştum
Müşterileri değildim ve Nix'i sadece evde kullanıyorum ama self-host etme yoluna kesinlikle bakacağım
Şu kısım olmasaydı tamamen konu dışı olurdu:
“Ama garnix codebase'ini açık kaynak yapıyoruz; buradan görebilirsiniz”
Bence bu kısmı konuya uygun ve ilginç kılıyor
Şirkette Nix'e tamamen yatırım yapıyoruz ve bu konuda hislerim epey karışık
Olumsuz duyguların büyük kısmı, Nix'in gerçekten harika bir teknoloji olmasına rağmen hâlâ çok genç bir uzaylı kalıntısı gibi hissettirmesinden geliyor
Nix'te yapılacak o kadar çok ilginç ve değerli iş var ki bu da heyecan verici
Nix'i benimsemek, mevcut platformların yıllar içinde biriktirdiği birçok konfor özelliğinden vazgeçmek anlamına geliyor; bu yüzden Garnix dahil Nix ekosistemindeki çeşitli araçlara bakıyordum
Şirkette gerçekten de normalde bedavaya gelen “temel” özellikler için çok daha fazla emek harcıyoruz
Örneğin GitHub Actions üzerinde doğrulamaları çalıştırmak sıradan bir projeye göre daha karmaşık ve caching, paralelleştirme gibi unsurlar sağlam ve hızlı build'ler için çok önemli
Nix ekosistemini geliştiren şirketlerin çok büyüyeceğini ya da birilerinin Nix devlerinin omuzlarında dünyayı sarsacak bir şey inşa edeceğini düşünüyorum
Ne yazık ki Garnix, daha büyük bir yapının içine çekilen öncülerden biri gibi görünüyor
Docker'dan birkaç yıl önce çıktı; sadece geç çiçek açan bir teknoloji olduğu için popülerliğini ancak yakın zamanda kazandı
garnix artık açık kaynak olduğuna göre onu GitHub'dan ayırmanın ne kadar zor olacağını merak ediyorum
Flake'den ayırmak oldukça kolay olmalı. flake gerçek değil ve size zarar veremez
Bu ihtimal gerçekten heyecan verici
Konuyu biraz kaçıracağım ama CI'ı Nix'e taşımaya çalışıyorum ve geliştirme/CI ortamı büyük
Bunun ana nedeni birden fazla tam tarayıcı içermesi ve nix build ya da cache restore ihtiyacını nasıl önleyeceğimi bulamıyorum
1Gbit bağlantıda 10GB geri yüklemek bile fazla yavaş
Docker'da bu sorun self-hosted runner kullanınca çözülmüş oluyor
Bir Docker image'ı oluşturup CI runner'ının çalıştığı host üzerinde cache olarak tutuyorsunuz
Ama Nix'te bunun nasıl yapıldığını bilmiyorum
İçinde geliştirme ortamı için gereken her şey zaten bulunan bir nix store'u paylaşmanın bir yoluna ihtiyacım var ve bunun, repoya commit edilmiş gerçek geliştirme ortamı flake'inden türetilmesi gerekiyor
Böyle bir şey yokmuş gibi gelmiyor mu?
/nix/store'u önceden doldursan, OCI image'ında olduğu gibi zaten orada durmaz mı?Önceki iş yerimde self-hosted GitLab runner'lar çalıştırıyorduk ve servis devreye girmeden önce en yeni build çıktıları kümesini instantiate edip önceden ısıtıyorduk
Sonra job'lar
/nix/storeiçinde cache'lenenleri doğrudan kullanıyordu