Garnix กำลังยุติให้บริการ

 (discourse.nixos.org)
1 คะแนน โดย GN⁺ 18 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • garnix มีกำหนดยุติบริการโฮสติ้งในวันที่ 15 กรกฎาคม 2026 ระหว่างกระบวนการเปลี่ยนผ่านไปรวมกับ Shopify
  • โค้ดเบสของ garnix จะถูกเผยแพร่เป็นโอเพนซอร์ส เพื่อให้ผู้ใช้ย้ายไปยังอินสแตนซ์ของตนเองหรืออินสแตนซ์ที่ใช้ร่วมกันได้
  • ผู้ใช้ที่สนใจดูแล community instance แบบสาธารณะสามารถติดต่อทีม garnix ได้ และทางทีมก็ต้องการพูดคุยในเรื่องนี้เช่นกัน
  • ในวันที่ 15 กรกฎาคม 2026 ข้อมูลผู้ใช้ทั้งหมดจะถูกลบ และรวมถึง build artifacts ด้วย
  • ข้อมูลและ build artifacts ที่ต้องการเก็บไว้จำเป็นต้องดาวน์โหลดด้วยตนเองก่อนวันยุติบริการ โดยประกาศปัจจุบันถูกแชร์ในรูปแบบการอ้างอิงอีเมล

การยุติบริการและการเปิดโค้ด

  • garnix กำลังเข้าร่วมกับ Shopify และเป็นส่วนหนึ่งของการเปลี่ยนผ่านครั้งนี้ บริการ garnix แบบโฮสต์จะยุติลงในวันที่ 15 กรกฎาคม 2026
  • โค้ดเบสของ garnix จะถูกเปิดเป็นโอเพนซอร์ส เพื่อให้ผู้ใช้ย้ายไปยังอินสแตนซ์ของตนเองหรืออินสแตนซ์ที่ใช้ร่วมกันได้
  • ผู้ใช้ที่สนใจดูแล community instance แบบสาธารณะสามารถติดต่อทีม garnix ได้

ข้อมูลผู้ใช้และการเตรียมย้ายระบบ

  • ในวันที่ 15 กรกฎาคม 2026 ข้อมูลผู้ใช้ทั้งหมดจะถูกลบ รวมถึง build artifacts
  • ข้อมูลหรือ build artifacts ที่ต้องการเก็บไว้จำเป็นต้องดาวน์โหลดด้วยตนเองก่อนวันยุติบริการ
  • ไม่พบประกาศการยุติบริการบน garnix.io และเนื้อหานี้ถูกแชร์ในรูปแบบการอ้างอิงจากอีเมลที่ได้รับจาก contact@garnix.io
  • ทีม garnix กล่าวขอบคุณการสนับสนุนจากชุมชน รวมถึงการบริจาคและฟีดแบ็กตั้งแต่สมัย Open Collective โดยระบุสมาชิกทีมคือ Alex David, Sönke Hahn และ Julian K. Arni

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 18 시간 전
ความเห็นจาก Lobste.rs

  • น่าเสียดายจริง ๆ! ชอบบทความที่อธิบายการฝัง service dependency URL เข้าไปใน service build เพื่อแก้ปัญหา rolling deploy มาก
    https://garnix.io/blog/call-by-hash/

  • สำหรับคนที่สงสัยว่า Garnix คืออะไร:
    Garnix คือบริการ CI สำหรับ คลังเก็บ GitHub แบบ flake ที่ทำเป็น Nix แล้ว
    ที่มา: https://github.com/garnix-io/garnix-ci#garnix

  • Garnix เป็นระบบ CI ที่ดีที่สุดแบบทิ้งห่างที่เคยใช้มา
    ตอนที่ GitHub Actions ยังหา runner ไม่เจอ Garnix ก็ build เสร็จไปแล้ว และแม้แต่ โปรเจกต์ Rust ที่มีความซับซ้อนระดับกลางของฉันก็มักเสร็จภายใน 1 นาที
    ถ้าเปลี่ยนแค่เอกสารก็ยิ่งเร็วกว่า และมันก็ build เอกสารจริง ๆ ด้วย
    แน่นอนว่าส่วนหนึ่งเป็นเพราะ Nix แต่ Garnix ก็ทำ integration นั้นได้ดีมากจริง ๆ
    CI ที่ผสานกับระบบ build สามารถทำงานได้ดีกว่าวิธีที่ต้องโหลด tar ของไฟล์ระบบครึ่งก้อนจาก S3 ทุกครั้งแล้วค่อยแปะแคชเข้าไปมาก
    แถมเพราะมันอิงกับ Nix จึง build สิ่งเดียวกับที่ build บนเครื่อง local แบบเป๊ะ ๆ ดังนั้นจึงไม่มีวงจร feedback ยาว ๆ แบบ “แก้ yaml ที่พิมพ์ผิด, push, รอ 10 นาที, ดู error ถัดไป, เพิ่ม debug output, push อีกครั้ง...”
    ถ้า build บนเครื่อง local ได้ มันก็ทำงานบน CI ได้

  • น่าเสียดายเหมือนกัน ช่วงสัปดาห์ที่ผ่านมาพอเห็นปัญหาแปลก ๆ อยู่บ้าง แต่ก็ไม่ได้ใส่ใจมาก
    ฉันไม่ค่อยชอบที่มันรองรับแค่ GitHub แต่ถึงอย่างนั้นก็ยังเป็นบริการที่ยอดเยี่ยม
    สุดสัปดาห์นี้กะว่าจะลองดู เวอร์ชันโอเพนซอร์ส แล้วประเมินว่าการ self-host จะใช้งานได้จริงไหม และถ้าใครมีทางเลือกอื่นสำหรับ Nix build ก็บอกกันได้

  • ใช้ garnix มาตั้งแต่เปิดตัว เลยค่อนข้างเสียดายที่มันจะปิดตัว
    ถ้าใครรู้จัก Nix CI หรือทางแก้ที่ self-host ได้ก็บอกกันหน่อย
    ส่วนใหญ่ฉันใช้ garnix เป็น cache และยังตั้ง workflow สำหรับ auto-merge ไว้โดยอิงจากสถานะ check ที่เปิดเผยต่อสาธารณะด้วย

    • ทาง tangled.org กำลังจะปล่อยของที่คล้ายกันเร็ว ๆ นี้ น่าจะ self-host ได้ด้วย
    • ดูเหมือน garnix จะถูกเปิดโอเพนซอร์สแล้ว ดังนั้นก็อาจเป็นตัวเลือกสำหรับ self-host ได้
      ฉันไม่ใช่ลูกค้าและใช้ Nix แค่ที่บ้าน แต่ตั้งใจจะลองดูวิธี self-host แน่นอน

  • ถ้าไม่มีข้อความต่อไปนี้ มันคงนอกประเด็นไปเต็ม ๆ:
    “แต่เรากำลังเปิดซอร์สโค้ดของ garnix และสามารถดูได้ที่นี่”
    ฉันว่าตรงนี้ยังเข้าประเด็นและน่าสนใจ
    ที่บริษัทกำลัง ทุ่มลงทุนกับ Nix ทั้งหมด อยู่ เลยมีความรู้สึกค่อนข้างซับซ้อน
    ความรู้สึกด้านลบส่วนใหญ่มาจากการที่ Nix เป็นเทคโนโลยีที่ยอดเยี่ยมมาก แต่ก็ยังให้ความรู้สึกเหมือนวัตถุโบราณจากต่างดาวที่ยังอายุน้อยมาก
    Nix น่าตื่นเต้นเพราะยังมีเรื่องที่น่าสนใจและมีคุณค่าให้ทำอีกมหาศาล
    การนำ Nix มาใช้หมายถึงการต้องยอมสละฟีเจอร์อำนวยความสะดวกจำนวนมากที่แพลตฟอร์มเดิม ๆ สั่งสมมานาน ดังนั้นเราจึงกำลังดูเครื่องมือต่าง ๆ ใน ecosystem ของ Nix รวมถึง Garnix ด้วย
    ในทางปฏิบัติ ที่บริษัทกำลังทุ่มแรงไปกับฟีเจอร์ “พื้นฐาน” ที่ปกติแล้วควรได้มาฟรีมากกว่าที่ควรจะเป็น
    ตัวอย่างเช่น แค่รันการตรวจสอบบน GitHub Actions ก็ซับซ้อนกว่าปกติสำหรับโปรเจกต์ทั่วไปแล้ว และองค์ประกอบอย่างการ cache กับการทำงานแบบขนานก็สำคัญมากต่อ build ที่เสถียรและรวดเร็ว
    ฉันคิดว่าบริษัทที่พัฒนา ecosystem ของ Nix จะเติบโตอย่างมาก หรือไม่ก็จะมีใครสักคนสร้างบางอย่างที่สั่นสะเทือนโลกบน ไหล่ของยักษ์แห่ง Nix
    น่าเสียดายที่ Garnix ดูเหมือนจะเป็นหนึ่งในผู้บุกเบิกที่ถูกดูดซึมเข้าไปอยู่ในองค์กรที่ใหญ่กว่า

    • ข้อเท็จจริงที่น่าสนใจก็คือ Nix ไม่ได้ใหม่ขนาดนั้น
      มันออกมาก่อน Docker หลายปี เพียงแต่เป็นเทคโนโลยีที่เพิ่งมาบูมช้า เลยเพิ่งได้รับความนิยมในช่วงหลัง

  • ตอนนี้ที่ garnix กลายเป็นโอเพนซอร์สแล้ว ก็สงสัยว่าการ แยกออกจาก GitHub จะยากแค่ไหน
    การแยกจาก flake น่าจะค่อนข้างง่ายนะ flake ไม่ใช่ของจริงและทำร้ายคุณไม่ได้

  • ขอแย่งประเด็นนิดหน่อย ฉันกำลังพยายามย้าย CI ไปใช้ Nix แต่สภาพแวดล้อม dev/CI มันใหญ่มาก
    สาเหตุหลักคือมีทั้งเบราว์เซอร์หลายตัวรวมอยู่ด้วย และฉันหาวิธีเลี่ยง nix build หรือการ restore cache ไม่เจอ
    แม้แต่การ restore ข้อมูล 10GB บนเครือข่าย 1Gbit ก็ยังช้าเกินไป
    Docker แก้ปัญหานี้ได้อยู่แล้วถ้าใช้ runner แบบ self-host
    แค่สร้าง Docker image แล้วเก็บไว้เป็น cache บนโฮสต์ที่ CI runner จะลุกขึ้นมาทำงาน
    แต่ใน Nix ฉันไม่รู้ว่าต้องทำแบบนั้นอย่างไร
    ฉันต้องการวิธีแชร์ nix store ที่มีทุกอย่างที่ต้องใช้สำหรับสภาพแวดล้อม dev อยู่แล้ว และ store นั้นก็ควร derive มาจาก flake ของสภาพแวดล้อม dev จริงที่ check in ไว้ใน repo
    มันเหมือนไม่มีอะไรแบบนี้อยู่เลยใช่ไหม?

    • ฉันไม่ค่อยเข้าใจ ถ้าคุณโฮสต์ runner เองและ pre-populate /nix/store ด้วยสิ่งที่ workflow นั้นต้องใช้ มันก็แค่มีอยู่ตรงนั้นเหมือนกับ OCI image ไม่ใช่เหรอ?
      ที่บริษัทเก่าของฉันเราใช้ self-hosted GitLab runner และก่อนนำ instance เข้าใช้งานกับ service เราจะ instantiate ชุด build artifact ล่าสุดไว้ล่วงหน้าเพื่ออุ่นเครื่อง
      จากนั้น job ต่าง ๆ ก็จะใช้ของที่ cache อยู่ใน /nix/store ได้เลย