CI ขนาดเล็กด้วย Git hook และ nq

 (mccd.space)
1 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นการตั้งค่า CI แบบง่ายที่เพิ่ม post-receive hook ลงใน bare Git repository บนเซิร์ฟเวอร์ส่วนตัว เพื่อทำการทดสอบ บิลด์ และย้ายไฟล์โดยอัตโนมัติ
  • CI แบบเดิมมีการตั้งค่า YAML ที่ซับซ้อน การรันที่ช้า และการโฮสต์เองที่ยุ่งยาก ขณะที่ไม่ได้ต้องการถึงขั้นการแยกสภาพแวดล้อมบิลด์อย่างสมบูรณ์หรือการจัดการข้อมูลลับ
  • หากรันงานโดยตรงใน hook เมื่อเกิดความล้มเหลว push อาจถูกปฏิเสธ หรือการเสร็จสิ้นอาจล่าช้า จึงใช้คิวงานขนาดเล็ก nq เพื่อประมวลผลในแบ็กกราวด์
  • hook จะเรียกเพียง nq เท่านั้น และตรวจสอบล็อกด้วย ssh server nqtail -a ทำให้ดูแลระบบได้รวดเร็วและเรียบง่าย
  • หากจำเป็น สามารถแยกบิลด์ด้วย landdown·Podman และจัดการข้อมูลลับด้วย sops หรือขยายวิธีพัฒนาด้วย Git email patch, git-shell, git http-backend ได้

การตั้งค่า post-receive hook และ nq

  • บนเซิร์ฟเวอร์ส่วนตัว สร้าง repository ด้วย ssh server git init --bare repo แล้ว clone ด้วย git clone server:repo
  • ใส่ post-receive hook ในรูปแบบสคริปต์ shell ลงในไดเรกทอรี hooks ของ bare repository เพื่อเริ่ม CI ทุกครั้งที่มีการ push
  • หากรันงานโดยตรงใน hook จะเกิดปัญหาสองอย่าง
    • หากสคริปต์ล้มเหลว push จะถูกปฏิเสธ
    • หากการรันสคริปต์ช้า การเสร็จสิ้นของ push ก็จะล่าช้าไปด้วย
  • ใน hook จะเรียกคิวงานขนาดเล็ก nq เพื่อเพิ่มงานเข้า คิวแบ็กกราวด์
    • ตรวจสอบล็อกด้วย ssh server nqtail -a
    • ดูขั้นตอนการตั้งค่าได้ใน tutorial สั้น ๆ

การแยกสภาพแวดล้อมและการขยายวิธีพัฒนา

  • หากต้องการรันบิลด์ใน sandbox สามารถใช้ landdown ได้
  • สามารถแยกบิลด์ออกจากสภาพแวดล้อมของโฮสต์ด้วย Podman หรือจัดการข้อมูลลับด้วย sops ได้
  • สำหรับการพัฒนาแบบ bazaar การตั้งค่าให้รับ Git patch ทางอีเมลจะเหมาะสม
  • การพัฒนาแบบ cathedral สามารถตั้งค่าด้วย git-shell หรือ git http-backend ได้

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

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

 
GN⁺ 8 시간 전
ความคิดเห็นบน Lobste.rs

  • CI มีปัญหาอย่างน้อยสองอย่าง
    ปัญหาง่ายคือการรัน make test เมื่อมีการเปลี่ยนแปลงโค้ด ส่วนปัญหายากคือการรัน make test บน Linux, Windows และ Mac ทั้งหมด

    • Linux ง่าย ส่วน Windows ยาก แต่ macOS นั้นเจ็บปวดถึงขั้นทรมาน
    • มองว่าส่วนที่ยากของ CI คือ เอนจินรันงาน ที่รองรับการดีบักเมื่อเกิดความล้มเหลว
      ไม่พอใจกับ developer experience และความสามารถในการดีบักของเอนจินที่มีอยู่ซึ่งมักถูกมองข้าม จึงกำลังสร้างระบบ CI ที่ https://ci.pico.sh ไม่ชอบ DSL ด้วย และ YAML แบบซ้อนเป็นลำดับชั้นให้ความรู้สึกเหมือนค่อย ๆ ดูดพลังชีวิตออกไป
    • วิธีนี้แก้ปัญหาง่ายได้ และอาจขยายไปสนับสนุนตระกูล BSD ด้วย QEMU รวมถึงหลายดิสโทรด้วย Docker ได้ แต่ถ้ามากกว่านั้นดูเหมือนจะต้องใช้ เครื่องมือที่ครบถ้วนกว่า

  • เคยสร้างสิ่งนี้บน gitolite แล้วส่งต่อไปยัง Temporal เพื่อควบคุมกระบวนการบิลด์ได้โดยไม่มีข้อจำกัด
    หากรันล้มเหลวก็สามารถปฏิเสธการ push ได้ แต่โดยทั่วไปจะปล่อยให้ผ่าน hook ก่อนแล้วค่อยจัดการความล้มเหลวแยกต่างหาก ซึ่งการตั้งค่าก็เรียบง่ายและสนุกดี

    • ชอบ เครื่องมือควบคุมการเข้าถึง ของ gitolite เป็นพิเศษ และวิธีที่สามารถ push ไปยัง repository ที่ยังไม่มีอยู่เพื่อสร้าง repository ใหม่ก็ยอดเยี่ยม

  • มี CI แบบมินิมอลอีกตัวที่เน้นการรัน shell script คือ laminar CI และยังมี เว็บ UI ให้ด้วย

  • นานมาแล้ว ในสภาพแวดล้อมองค์กรที่ใช้ Windows เท่านั้น เคยวาง Mac mini เป็น เซิร์ฟเวอร์ CI ภายในเครื่อง ที่ทั้งทีมใช้ เพื่อบิลด์แอป iOS และเป็นหนึ่งในวิธีใช้ Git ที่ลองทำตั้งแต่ช่วงแรก ๆ

  • พบจาก https://mccd.space/git/ และดูเหมือนจะใช้ fork ของ stagit
    จนถึงไม่กี่เดือนก่อนเคยรัน Forgejo กับ Woodpecker แต่ฟีเจอร์ส่วนใหญ่ไม่จำเป็น จึงถอดออกทั้งหมดและกำลังมองหา ชุดตั้งค่าที่เบากว่า คล้าย ๆ แบบนี้อยู่ งานถัดไปคือ CI พอดีจึงมาได้ถูกเวลา และกำลังคิดอยู่ว่าจะ mirror ไลบรารีเล็ก ๆ ที่จะเปิดเร็ว ๆ นี้ไปยัง SourceHut หรือไม่

    • fork stagit เพื่อเพิ่มอีเมลติดต่อและแถบนำทาง ใส่ ID สำหรับปรับ CSS และลบข้อมูลที่ไม่จำเป็นออก
      repository เปิดให้อ่านแบบ read-only บนเว็บผ่าน git-daemon และได้สรุปวิธีตั้งค่าทั้งหมดไว้ ที่นี่

  • เพิ่งรู้จัก nq จากบทความนี้ แต่คงจะใช้ systemd-run มากกว่า
    เนื่องจากใช้ Nix กับ runner แทบทั้งหมดอยู่แล้ว หากเปิดเผยผลลัพธ์ของ nix flake check เป็นเมตริกและล็อก OTLP ก็น่าจะตอบโจทย์ CI ด้วยระบบมอนิเตอร์ได้

  • ชอบการจัดวางแพลตฟอร์มพัฒนาแบบ self-hosted ที่เรียบง่ายเช่นนี้
    สามารถตั้งค่าและใช้งาน bubblewrap ซึ่งเป็นระบบคอนเทนเนอร์ที่เบาและเรียบง่ายสำหรับ CI ได้ง่าย อย่างไรก็ตามถ้าใช้ nq ดูเหมือนจะ ปฏิเสธการ push เมื่อ CI ล้มเหลว ไม่ได้ เลยสงสัยว่าจัดการกันอย่างไร

    • มี เครื่องมือเสริม ที่ใช้ Landlock เพื่อจำกัดสคริปต์ด้วย และคิดว่าวิธีใช้เรียบง่ายกว่าเล็กน้อย
      หากต้องการ isolation มากขึ้นก็เพิ่ม Podman, Docker หรือ bubblewrap ได้ ไม่ปฏิเสธการ push เมื่อ CI ล้มเหลวด้วยเหตุผลเดียวกับที่ไม่ใส่ pre-commit hook ที่รันเทสต์ เพราะบางครั้งก็จำเป็นต้อง commit หรือ push งานที่พังอยู่ และการ push อาจช้ามากได้ หากต้องการปฏิเสธ ก็ให้รัน CI แบบ synchronous โดยไม่ใช้ nq แล้วบล็อกการ push เมื่อ exit code ไม่ใช่ 0
      หรือจะให้ บรานช์ที่ไม่ใช่ main รันด้วย nq และรันแบบ synchronous เฉพาะบรานช์ main ก็ได้

  • ดูเหมือนว่า ลิงก์ landdown จะเสีย