1 điểm bởi GN⁺ 18 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • garnix sẽ chấm dứt dịch vụ hosting vào ngày 15 tháng 7 năm 2026 trong quá trình chuyển đổi khi gia nhập Shopify
  • codebase của garnix sẽ được mở nguồn, cho phép người dùng chuyển sang instance tự vận hành hoặc instance dùng chung
  • Người dùng quan tâm đến việc vận hành instance cộng đồng công khai có thể liên hệ với đội ngũ garnix, và đội ngũ cũng muốn trao đổi về việc này
  • Vào ngày 15 tháng 7 năm 2026, toàn bộ dữ liệu người dùng sẽ bị xóa, bao gồm cả các build artifact
  • Dữ liệu và build artifact cần lưu giữ phải được tải xuống trực tiếp trước ngày ngừng hoạt động; thông báo hiện tại được chia sẻ dưới dạng trích dẫn từ email

Dừng dịch vụ và công khai mã nguồn

  • garnix gia nhập Shopify và, như một phần của quá trình chuyển đổi này, sẽ ngừng dịch vụ garnix được host vào ngày 15 tháng 7 năm 2026
  • Codebase của garnix sẽ được mở nguồn để người dùng có thể chuyển sang instance tự vận hành hoặc instance dùng chung
  • Người dùng quan tâm đến việc vận hành instance cộng đồng công khai có thể liên hệ với đội ngũ garnix

Dữ liệu người dùng và chuẩn bị di chuyển

  • Vào ngày 15 tháng 7 năm 2026, toàn bộ dữ liệu người dùng sẽ bị xóa, bao gồm cả build artifact
  • Dữ liệu hoặc build artifact cần lưu giữ phải được tải xuống trực tiếp trước ngày ngừng hoạt động
  • Thông báo ngừng hoạt động không được xác nhận trên garnix.io và được chia sẻ dưới dạng trích dẫn nội dung email nhận từ contact@garnix.io
  • Đội ngũ garnix gửi lời cảm ơn đến sự hỗ trợ của cộng đồng, bao gồm các khoản đóng góp và phản hồi từ thời Open Collective; các thành viên của đội gồm Alex David, Sönke Hahn và Julian K. Arni

1 bình luận

 
Ý kiến trên Lobste.rs
  • Đáng tiếc thật! Tôi rất thích bài viết nói về việc nhúng URL phụ thuộc dịch vụ vào bản build dịch vụ để giải quyết vấn đề triển khai rolling
    https://garnix.io/blog/call-by-hash/

  • Dành cho ai thắc mắc Garnix là gì:
    Garnix là dịch vụ CI cho các kho GitHub đã được Nix hóa dựa trên flake
    Nguồn: https://github.com/garnix-io/garnix-ci#garnix

  • Garnix vượt trội là hệ thống CI tốt nhất tôi từng dùng
    Khi GitHub Actions còn đang đi tìm runner thì Garnix đã build xong, và cả dự án Rust có độ phức tạp vừa phải của tôi cũng thường hoàn tất trong vòng 1 phút
    Khi chỉ thay đổi tài liệu thì còn nhanh hơn nữa, mà tài liệu vẫn được build thật
    Tất nhiên là nhờ Nix, nhưng Garnix đã tích hợp nó cực kỳ tốt
    CI tích hợp với hệ thống build có thể hoạt động tốt hơn nhiều so với cách mỗi lần tải về một file tar nửa cái filesystem từ S3 rồi chồng cache lên trên
    Thêm nữa, vì dựa trên Nix nên nó build đúng y như thứ bạn build ở máy cục bộ, vì vậy không có vòng phản hồi dài kiểu “sửa lỗi gõ nhầm trong yaml, push, đợi 10 phút, xem lỗi tiếp theo, thêm output debug, lại push...”
    Nếu build được ở local thì nó cũng chạy được trên CI

  • Tiếc thật. Khoảng một tuần gần đây tôi có thấy vài vấn đề lạ nhưng cũng không quá để tâm
    Tôi hơi không hài lòng vì nó chỉ hỗ trợ GitHub, nhưng dù vậy vẫn là một dịch vụ tuyệt vời
    Cuối tuần này tôi định xem thử phiên bản mã nguồn mở để đánh giá xem tự host có khả thi không, và sẽ rất tốt nếu ai đó có thể gợi ý các lựa chọn thay thế cho Nix build

  • Tôi đã dùng garnix từ lúc ra mắt nên việc nó đóng cửa khá đáng tiếc
    Nếu ai biết giải pháp Nix CI hoặc giải pháp có thể tự host thì mong được chia sẻ
    Tôi chủ yếu dùng garnix làm cache, và cũng đã dựng workflow tự động merge dựa trên trạng thái check công khai

    • tangled.org sắp công bố thứ gì đó tương tự. Có lẽ cũng sẽ hỗ trợ tự host
    • có vẻ garnix đang được mở mã nguồn nên cũng có thể trở thành một ứng viên để tự host
      Tôi không phải khách hàng, chỉ dùng Nix ở nhà thôi, nhưng chắc chắn sẽ xem thử cách tự host
  • Nếu không có đoạn sau thì đã hoàn toàn lạc đề, nhưng:
    “Nhưng chúng tôi đang phát hành mã nguồn của garnix theo giấy phép mã nguồn mở, bạn có thể xem tại đây
    Theo tôi phần này vẫn đúng chủ đề và khá thú vị
    Công ty tôi đang đầu tư toàn diện vào Nix, nên cảm xúc khá lẫn lộn
    Phần lớn cảm giác tiêu cực đến từ việc Nix là một công nghệ thật sự tuyệt vời nhưng vẫn cho cảm giác như một di vật ngoài hành tinh còn rất non trẻ
    Nix còn cả một khối lượng khổng lồ những việc thú vị và đáng giá đang chờ được làm nên điều đó rất đáng mong đợi
    Việc áp dụng Nix đồng nghĩa với việc từ bỏ kha khá tính năng tiện lợi mà các nền tảng hiện có đã tích lũy suốt thời gian dài, nên tôi đã tìm hiểu Garnix và nhiều công cụ khác trong hệ sinh thái Nix
    Thực tế ở công ty, chúng tôi đang phải bỏ nhiều công sức hơn cho các tính năng “cơ bản” vốn bình thường sẽ có sẵn miễn phí
    Ví dụ, chỉ riêng việc chạy kiểm tra trong GitHub Actions cũng phức tạp hơn so với một dự án thông thường, và các yếu tố như caching, song song hóa cực kỳ quan trọng để có các bản build nhanh và ổn định
    Tôi nghĩ các công ty đang phát triển hệ sinh thái Nix либо sẽ tăng trưởng rất mạnh, hoặc sẽ có ai đó xây nên một thứ làm rung chuyển thế giới trên vai của những người khổng lồ Nix
    Đáng tiếc là Garnix trông giống như một trong những người tiên phong đã bị hấp thụ vào một tổ chức lớn hơn

    • Điều thú vị là Nix thực ra không trẻ đến vậy
      Nó ra đời sớm hơn Docker vài năm, chỉ là một công nghệ nở muộn nên gần đây mới bắt đầu được ưa chuộng
  • Giờ khi garnix đã mã nguồn mở, tôi tự hỏi sẽ khó đến mức nào để tách nó khỏi GitHub
    Tách nó khỏi flake thì chắc phải khá dễ. flake không có thật và không thể làm hại bạn

  • Hơi lạc đề một chút, nhưng tôi đang định chuyển CI sang Nix và môi trường dev/CI thì rất lớn
    Lý do chính là nó chứa nhiều bản cài của cả trình duyệt, và tôi không tìm ra cách nào để tránh nix build hoặc khôi phục cache
    Ngay cả việc khôi phục 10GB trên đường truyền 1Gbit cũng quá chậm
    Với Docker thì vấn đề này đã được giải quyết nếu dùng runner tự host
    Bạn chỉ cần tạo image Docker và giữ nó làm cache trên host nơi runner CI được khởi chạy
    Nhưng với Nix thì tôi không biết làm sao để làm điều đó
    Tôi cần một cách để chia sẻ nix store đã chứa sẵn mọi thứ cần cho môi trường phát triển, và store đó phải được suy ra từ flake môi trường dev thực tế đã được commit trong kho
    Có vẻ như thứ như vậy không tồn tại, đúng không?

    • Tôi không chắc mình hiểu đúng. Nếu bạn tự host runner và làm nóng sẵn /nix/store với những gì workflow đó cần, thì cũng giống như OCI image thôi, chẳng phải mọi thứ sẽ cứ nằm sẵn ở đó sao?
      Ở công ty cũ, chúng tôi từng vận hành runner GitLab tự host và làm ấm sẵn bằng cách hiện thực hóa một tập các đầu ra build gần đây trước khi đưa vào phục vụ
      Khi đó các job sẽ dùng nguyên những gì đã được cache trong /nix/store