Garnix akan dihentikan

• garnix akan menghentikan layanan hostingnya pada 15 Juli 2026 sebagai bagian dari proses transisi bergabung dengan Shopify
• codebase garnix akan dirilis sebagai open source, sehingga pengguna dapat bermigrasi ke instance sendiri atau instance bersama
• Pengguna yang tertarik mengoperasikan instance komunitas publik dapat menghubungi tim garnix, dan tim juga ingin berdiskusi terkait hal itu
• Pada 15 Juli 2026, semua data pengguna akan dihapus, dan hasil build juga termasuk dalam objek yang akan dihapus
• Data dan hasil build yang ingin disimpan harus diunduh sendiri sebelum tanggal penghentian, dan pengumuman saat ini dibagikan dalam bentuk kutipan email

---

Penghentian layanan dan pembukaan kode

• garnix bergabung dengan Shopify, dan sebagai bagian dari transisi ini layanan garnix yang di-host akan dihentikan pada 15 Juli 2026
• codebase garnix akan dirilis sebagai open source sehingga pengguna dapat berpindah ke instance sendiri atau instance bersama
• Pengguna yang tertarik mengoperasikan instance komunitas publik dapat menghubungi tim garnix

Data pengguna dan persiapan migrasi

• Pada 15 Juli 2026, semua data pengguna akan dihapus, termasuk hasil build
• Data atau hasil build yang ingin disimpan harus diunduh sendiri sebelum tanggal penghentian
• Pengumuman penghentian tidak ditemukan di garnix.io, dan dibagikan dalam bentuk kutipan isi email yang diterima dari [e-mail]
• Tim garnix menyampaikan terima kasih atas dukungan komunitas, termasuk donasi dan masukan pada masa Open Collective, dan anggota tim yang disebutkan adalah Alex David, Sönke Hahn, Julian K. Arni

[GN⁺]

Pendapat di Lobste.rs

• Sayang sekali! Saya sangat menyukai tulisan tentang menyematkan URL dependensi layanan ke dalam build layanan untuk menyelesaikan masalah rolling deployment
  https://garnix.io/blog/call-by-hash/

• Buat yang penasaran apa itu Garnix:
  Garnix adalah layanan CI untuk repositori GitHub berbasis flake yang sudah di-Nix-kan
  Sumber: https://github.com/garnix-io/garnix-ci#garnix

• Garnix sejauh ini adalah sistem CI terbaik yang pernah saya pakai
  Saat GitHub Actions masih mencari runner, Garnix sudah selesai build, dan bahkan proyek Rust saya yang tingkat kerumitannya sedang pun biasanya selesai dalam 1 menit
  Saat yang berubah hanya dokumentasi, hasilnya bahkan lebih cepat, dan dokumentasinya benar-benar dibuild juga
  Tentu ini berkat Nix, tetapi Garnix melakukan integrasinya dengan sangat baik
  CI yang terintegrasi dengan sistem build bisa bekerja jauh lebih baik daripada pendekatan menambal cache dengan mengunduh tar setengah-filesystem dari S3 setiap kali
  Selain itu, karena berbasis Nix, ia membuild persis hal yang sama dengan yang dibuild secara lokal, jadi tidak ada loop umpan balik panjang seperti “memperbaiki typo yaml, push, tunggu 10 menit, lihat error berikutnya, tambahkan output debug, push lagi...”
  Kalau berhasil dibuild secara lokal, maka akan jalan juga di CI

• Disayangkan. Selama kira-kira seminggu terakhir saya sempat melihat beberapa masalah aneh, tapi tidak terlalu saya pikirkan
  Saya agak kurang suka karena hanya mendukung GitHub, tetapi tetap saja ini layanan yang hebat
  Akhir pekan ini saya berencana melihat versi open-source-nya dan menilai apakah self-hosting realistis, dan kalau ada alternatif build Nix lain akan bagus kalau diberi tahu

• Saya sudah memakai garnix sejak rilis, jadi cukup sedih mendengar layanan ini ditutup
  Kalau ada yang tahu solusi Nix CI atau yang bisa di-self-host, saya ingin tahu
  Saya terutama memakai garnix sebagai cache, dan juga sudah menyiapkan workflow auto-merge berdasarkan status check yang dipublikasikan

  • tangled.org akan segera merilis sesuatu yang mirip. Sepertinya self-hosting juga akan dimungkinkan
  • sepertinya garnix akan dirilis sebagai open-source, jadi itu juga bisa menjadi kandidat untuk self-hosting
    Saya bukan pelanggan dan hanya memakai Nix di rumah, tetapi saya pasti akan melihat bagaimana cara menjalankannya sendiri

• Kalau bukan karena isi berikut, ini akan benar-benar di luar topik:
  “Tetapi kami merilis codebase garnix sebagai open-source, dan bisa dilihat di sini”
  Bagian ini menurut saya relevan dan menarik
  Di kantor kami berinvestasi penuh pada Nix, jadi perasaan saya cukup campur aduk
  Sebagian besar kesan negatif itu datang dari kenyataan bahwa Nix adalah teknologi yang benar-benar hebat, tetapi masih terasa seperti artefak alien yang sangat muda
  Nix sangat menarik dan masih banyak sekali hal bernilai yang menunggu untuk dikerjakan, jadi saya antusias
  Mengadopsi Nix berarti melepaskan cukup banyak fitur kenyamanan yang selama ini dibangun platform-platform lain dalam waktu lama, jadi saya sedang melihat Garnix dan berbagai alat lain di ekosistem Nix
  Dalam praktiknya, di perusahaan kami menghabiskan jauh lebih banyak upaya pada fitur-fitur “dasar” yang biasanya didapat gratis
  Misalnya, menjalankan validasi di GitHub Actions juga lebih rumit daripada proyek biasa, dan elemen seperti caching serta paralelisasi sangat penting untuk build yang kokoh dan cepat
  Saya rasa perusahaan-perusahaan yang mengembangkan ekosistem Nix akan tumbuh besar, atau seseorang akan membuat sesuatu yang mengguncang dunia di atas bahu para raksasa Nix
  Sayangnya, Garnix tampak seperti salah satu pelopor yang terserap ke organisasi yang lebih besar

  • Fakta menariknya, Nix sebenarnya tidak semuda itu
    Ia muncul beberapa tahun lebih awal daripada Docker, hanya saja merupakan teknologi yang berkembang terlambat sehingga baru belakangan ini populer

• Sekarang setelah garnix menjadi open-source, saya penasaran seberapa sulit memisahkannya dari GitHub
  Memisahkannya dari flake seharusnya cukup mudah. flake itu tidak nyata dan tidak bisa menyakiti Anda

  • Setiap kali melihat garnix, saya merasa seperti Squidward yang iri melihat SpongeBob dan Patrick bersenang-senang dari jendela
    Kemungkinan ini jelas membuat saya antusias

• Sedikit membajak topik, saya sedang mencoba memindahkan CI ke Nix, tetapi lingkungan dev/CI kami besar
  Alasan utamanya karena ada beberapa browser utuh di dalamnya, dan saya belum menemukan cara untuk menghindari nix build atau pemulihan cache
  Bahkan memulihkan 10GB di lingkungan 1Gbit pun terlalu lambat
  Dengan Docker, masalah ini terpecahkan jika memakai runner yang di-self-host
  Cukup buat image Docker dan simpan sebagai cache di host tempat runner CI dijalankan
  Tetapi di Nix saya tidak tahu bagaimana melakukannya
  Saya butuh cara untuk berbagi nix store yang sudah berisi semua yang diperlukan lingkungan pengembangan, dan itu harus diturunkan dari flake lingkungan pengembangan aktual yang di-check-in ke repositori
  Rasanya seperti ini tidak ada, ya?

  • Saya kurang paham. Kalau Anda meng-host runner sendiri dan mengisi /nix/store terlebih dahulu dengan hal-hal yang diperlukan workflow itu, bukankah itu akan tetap ada begitu saja, sama seperti image OCI?
    Di tempat kerja lama kami mengoperasikan runner GitLab sendiri, dan sebelum dipakai untuk melayani, kami menginstansiasi sekumpulan artefak build terbaru untuk memanaskannya terlebih dahulu
    Setelah itu, job tinggal memakai apa yang sudah di-cache di /nix/store