Garnixが終了へ

 (discourse.nixos.org)
1 ポイント 投稿者 GN⁺ 18 시간 전 | 1件のコメント | WhatsAppで共有
  • garnix はShopifyへの合流に伴う移行の過程で、ホスティングサービスを2026年7月15日に終了する予定
  • garnix コードベース はオープンソースとして公開され、ユーザーは自前のインスタンスまたは共有インスタンスへ移行できるようになる
  • 公開 コミュニティインスタンス の運営に関心のあるユーザーはgarnixチームに連絡でき、チームもそのような対話を望んでいる
  • 2026年7月15日にすべての ユーザーデータ が削除され、ビルド成果物も削除対象に含まれる
  • 保存したいデータや ビルド成果物 は終了日までに各自でダウンロードする必要があり、今回の告知はメール引用の形で共有されている

サービス終了とコード公開

  • garnix はShopifyに合流し、この移行の一環としてホスト型のgarnixサービスを2026年7月15日に終了する
  • garnixコードベースはオープンソースとして公開され、ユーザーが自前のインスタンスまたは共有インスタンスへ移行できるようになる
  • 公開コミュニティインスタンスの運営に関心のあるユーザーはgarnixチームに連絡できる

ユーザーデータと移行準備

  • 2026年7月15日に すべてのユーザーデータ が削除され、ビルド成果物も含まれる
  • 保存したいデータやビルド成果物は終了日までに各自でダウンロードする必要がある
  • 終了告知は garnix.io では確認できず、contact@garnix.io から受け取ったメール内容の引用という形で共有されている
  • garnixチームは、Open Collective時代の寄付やフィードバックを含むコミュニティの支援に感謝を伝えており、チームメンバーとしてAlex David、Sönke Hahn、Julian K. Arniの名前が挙げられている

関連記事

1件のコメント

 
GN⁺ 18 시간 전
Lobste.rsのコメント

  • 残念ですね！ローリングデプロイの問題を解決するために、サービス依存URLをサービスビルドに埋め込むという記事が本当に好きでした
    https://garnix.io/blog/call-by-hash/

  • Garnixが何か気になる人のために言うと:
    GarnixはNix化されたflakeベースのGitHubリポジトリ向けCIサービスです
    出典: https://github.com/garnix-io/garnix-ci#garnix

  • Garnixは、これまで使ったCIシステムの中で圧倒的に最高でした
    GitHub Actionsがまだランナーを探している間に、Garnixはすでにビルドを終えていて、中程度の複雑さのRustプロジェクトでもたいてい1分以内に終わっていました
    ドキュメントだけを変更したときはさらに速く、しかもドキュメントも実際にビルドしていました
    もちろんNixのおかげでもありますが、Garnixはその統合を本当にうまくやっていました
    ビルドシステムと統合されたCIは、毎回S3からファイルシステム半分ぶんのtarをダウンロードしてキャッシュを継ぎ足す方式より、はるかにうまく機能し得ます
    しかもNixベースなので、ローカルでビルドするのとまったく同じものをビルドします。つまり、「yamlのタイプミスを直す → pushする → 10分待つ → 次のエラーを見る → デバッグ出力を追加する → またpushする…」のような長いフィードバックループがありません
    ローカルでビルドできれば、CIでも動きます

  • 残念です。ここ1週間ほど奇妙な問題をいくつか見かけていましたが、あまり気にしていませんでした
    GitHubしかサポートしていない点には少し不満がありましたが、それでも素晴らしいサービスでした
    週末にオープンソース版を見て、自前ホスティングが現実的かどうか判断してみるつもりですし、Nixビルドの代替案があれば教えてほしいです

  • リリース時からgarnixを使ってきたので、終了するのはかなり残念です
    Nix CIやセルフホスト可能な解決策を知っている人がいれば教えてほしいです
    主にgarnixをキャッシュとして使っていて、公開されたチェック結果をもとに自動マージのワークフローも組んでいました

    • tangled.orgが近いうちに似たものを公開する予定です。セルフホストも可能になるはずです
    • garnixはオープンソース化されるようなので、セルフホスト候補になるかもしれません
      顧客ではなく家でNixを使っているだけですが、セルフホストの方法はぜひ見てみるつもりです

  • 次の内容がなければ完全に話題から外れていましたが:
    「ただし、garnixのコードベースはオープンソースとして公開され、こちらで見ることができます」
    この部分は話題に沿っていて興味深いと思います
    会社でNixに全面投資しているので、感情はかなり複雑です
    ネガティブな感覚の大半は、Nixが本当に素晴らしい技術である一方で、いまだに非常に若い異星の遺物のように感じられることから来ています
    Nixには面白く価値ある仕事がまだ大量に残っていて、期待しています
    Nixを導入するというのは、既存プラットフォームが長年かけて積み上げてきた便利機能のかなりの部分を諦めることを意味するので、GarnixをはじめNixエコシステムのさまざまなツールを見ていました
    実際、会社では本来なら無料で手に入るはずの「基本」機能に、はるかに多くの労力を使っています
    たとえばGitHub Actionsで検証を回すことさえ、普通のプロジェクトより複雑で、キャッシュや並列化のような要素が堅牢で高速なビルドにとって非常に重要です
    Nixエコシステムを発展させる会社が大きく成長するか、あるいは誰かがNixの巨人たちの肩の上に世界を揺るがす何かを築くような気がします
    残念ながらGarnixは、より大きな組織に吸収された先駆者の一つのように見えます

    • 面白いことに、Nixはそれほど若いわけではありません
      Dockerより数年早く登場していて、ただ遅咲きの技術だったので最近になって人気が出たのです

  • garnixがオープンソースになった今、GitHubから切り離すのがどれくらい難しいのか気になります
    flakeから切り離すのはかなり簡単なはずです。flakeは本物ではないし、あなたを傷つけることもありません

  • 少し話題を横取りしますが、CIをNixに切り替えようとしていて、開発/CI環境が大きいです
    主な理由はブラウザ一式が複数入るからで、nix buildやキャッシュ復元を避ける方法が見つかりません
    1Gbit環境で10GBを復元するのでさえ遅すぎます
    Dockerならセルフホストランナーを使えばこの問題は解決済みです
    Dockerイメージを作って、CIランナーが立ち上がるホストにキャッシュとして保持しておけばいいだけです
    でもNixでこれをどうやるのか分かりません
    開発環境に必要なものがすべてすでに入っているnix storeを共有する方法が必要で、そのストアはリポジトリにチェックインされている実際の開発環境flakeから派生している必要があります
    こういうものって存在しないのでしょうか？

    • ちょっと何が問題なのかよく分かりません。ランナーを自前でホスティングして、そのワークフローに必要なものを /nix/store にあらかじめ入れておけば、OCIイメージと同じように、そこにあるだけではないですか？
      以前の職場ではセルフホストのGitLabランナーを運用していて、本番投入前に最近のビルド成果物一式をインスタンス化して事前に温めていました
      そうするとジョブは /nix/store にキャッシュされたものをそのまま使っていました