▲

Garnix가 종료됩니다

 (discourse.nixos.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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로 명시됨

함께 보면 좋은 글 β

▲
GN⁺   [-]
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에서도 동작함

  • 아쉽네요. 지난 일주일쯤 이상한 문제가 몇 개 보였지만 크게 신경 쓰지는 않았음
    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에 캐시된 것을 그대로 사용했음
답변달기