ความเจ็บปวดที่เกิดจาก GitHub Actions

 (feldera.com)
2 คะแนน โดย GN⁺ 2025-03-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • ปัญหาของ GitHub Actions

    • เมื่อไม่นานมานี้ ผู้เขียนใช้เวลาไปมากกับการเขียนสคริปต์ CI ใหม่ด้วย GitHub Actions ก่อนหน้านี้เคยใช้ Earthly แต่โครงการนั้นยุติไปแล้วจึงต้องกลับมาใช้ GitHub Actions อีกครั้ง
    • CI มีความซับซ้อน โดยมีทั้ง merge queue, runner หลายตัว, การ build Rust, Docker image, integration test และอื่น ๆ ทุกครั้งที่ merge PR จะใช้เวลา CI จำนวนมาก
    • ตามแนวปฏิบัติซอฟต์แวร์ที่ดี ทุกการทดสอบควรผ่าน ความผิดพลาดเล็กน้อยควรถูกแก้ไขอัตโนมัติ และ artifact ที่ผ่านการทดสอบแล้วควรเป็นตัวเดียวกับที่ใช้ปล่อย release ซึ่ง GitHub Actions ทำสิ่งเหล่านี้ได้ แต่การตั้งค่านั้นซับซ้อนและไม่สม่ำเสมอ

  • Status check และ merge queue

    • merge queue ของ GitHub จะนำ PR ไป rebase บน main branch แล้วจึงรัน CI แต่จำเป็นต้องรัน CI ทั้งก่อนและหลังนำเข้า queue และการตั้งค่าเรื่องนี้ทำได้ยาก
    • วิธีแก้คือกำหนดชื่องานให้เหมือนกันในทั้งสองขั้นตอน เพื่อให้จำเป็นต้องผ่านทั้งสองขั้นตอน

  • ปัญหาด้านความปลอดภัย

    • เมื่อไม่นานมานี้ GitHub Action ยอดนิยมตัวหนึ่งถูกเจาะ แนวทางตอบสนองที่มีการแนะนำคือให้ pin dependency ด้วย hash แต่ผู้ใช้ส่วนใหญ่ไม่ได้ทำเช่นนั้น
    • โมเดลความปลอดภัยของ GitHub มีความซับซ้อนและทำความเข้าใจได้ยาก แม้จะตั้งค่าสิทธิ์เริ่มต้นของ GITHUB_TOKEN ได้ แต่การเอาสิทธิ์ออกกลับไม่ชัดเจน
    • สิทธิ์ของ workflow ไม่ได้ขึ้นอยู่กับตัว action เอง และการยกระดับสิทธิ์จากภายในโค้ดก็ดูแปลกประหลาด

  • การใช้ Docker ร่วมกับ GitHub Actions

    • GitHub Actions สามารถรันงานภายในคอนเทนเนอร์ได้ แต่มีปัญหาเกิดขึ้นจากสิทธิ์ไฟล์และการเปลี่ยนตำแหน่งของไดเรกทอรี $HOME
    • ฟิลด์ container มีข้อจำกัดหลายอย่าง เช่น ไม่สามารถ override entrypoint หรือรันเฉพาะบางขั้นตอนภายในคอนเทนเนอร์ได้

  • การพัฒนา workflow ด้วย YAML

    • การเขียน logic ด้วย YAML อาจซับซ้อนและพลาดได้ง่าย ผู้เขียนใช้ IDE อย่าง RustRover เพื่อช่วยตรวจสอบบางส่วน แต่ยังต้องการการตรวจสอบแบบ static ที่ดีกว่านี้
    • การทดสอบบนเครื่อง local ทำได้ยาก จึงต้องสร้าง repo แยกที่เหมือนกัน แล้ว commit และ push ซ้ำ ๆ จนกว่า CI จะทำงานได้
    • ผู้เขียนพยายามทำให้ workflow มีขนาดเล็ก และ push artifact เพื่อให้นำไปใช้ซ้ำใน workflow อื่นได้ แต่การดาวน์โหลด artifact ต้องใช้ token

  • สรุป

    • แม้สคริปต์ CI ชุดใหม่จะช่วยลดเวลา merge ลงได้มาก แต่กระบวนการตั้งค่ายังซับซ้อนและ debug ได้ยาก จึงจำเป็นต้องมีนวัตกรรมใหม่

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

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

 
GN⁺ 2025-03-21
ความคิดเห็นจาก Hacker News

  • มีความเห็นว่า GitLab ดีกว่า แต่ GitLab ก็มีปัญหาในแบบของตัวเองเช่นกัน

    • จากการลองใช้เครื่องมือ CI หลายตัว สิ่งสำคัญคือเขียนลอจิกของ CI ลงในโค้ดของตัวเองให้มากที่สุดเท่าที่ทำได้
    • ควรลงทุนเพื่อให้สามารถรัน pipeline แบบโลคัลบนเครื่องของนักพัฒนาได้
    • ควรหลีกเลี่ยงการใช้ YAML ให้มากที่สุด
    • ไม่ควรพึ่งพาเครื่องมือใหม่ที่ได้รับเงินทุนจาก VC
    • ควรใช้ self-hosted runner ให้มากที่สุดเท่าที่ทำได้ และรันแบบ on-premises

  • น่าสนใจที่ GitHub Actions และ DevOps ถูกวิจารณ์อย่างกว้างขวาง

    • การตั้งค่าและการทดสอบอาจยุ่งยาก แต่ถ้ามันทำงานได้แล้วแทบไม่ต้องไปแตะมันอีก
    • ตลอด 4 ปีที่ผ่านมาแทบไม่ได้แก้ workflow เลย นอกจากอัปเดตเวอร์ชัน Node
    • โดยส่วนตัวแล้วค่อนข้างพอใจ

  • เคยใช้ GitLab แล้วเปลี่ยนมา GitHub แต่รู้สึกผิดหวัง

    • รู้สึกว่า GitHub Actions ด้อยกว่า GitLab มาก
    • ถ้าต้องเลือกใช้ในการดำเนินงานของบริษัท จะเลือก GitLab

  • วงจร feedback ที่กินเวลา 30-60 วินาทีนั้นแย่มาก

    • พยายามจำลองสภาพแวดล้อม GHA บนเครื่องโลคัล แต่ทำไม่ได้
    • ความผิดพลาดเล็กน้อยทำให้เสียเวลาไปมาก

  • ไม่ต้องการให้ CI แก้โค้ดโดยอัตโนมัติ

    • การตรวจสอบเล็กน้อยควรรันด้วย pre-commit hook

  • รู้สึกผิดหวังที่ดูเหมือนการพัฒนาของ GitHub Actions จะหยุดชะงัก

    • น่าเสียดายที่ Earthly และ Dagger หยุดพัฒนาไป
    • หลังจากประเมิน Depot.dev แล้ว พบว่าเป็นทีมที่ฉลาดมากและแก้ปัญหาได้ดี

  • GitHub Actions ทำให้มีการใช้คอนเทนเนอร์ในทางที่ผิดเป็นเหมือนสคริปต์ติดตั้ง

    • เวลาจำนวนมากใน workflow หมดไปกับการรันตัวติดตั้ง

  • การเลือกเครื่องมือให้เหมาะสมเป็นเรื่องสำคัญ

    • GitHub Actions เหมาะกับงานง่าย ๆ แต่ไม่เหมาะกับงานที่ซับซ้อน

  • เนื่องจากปัญหาด้านความปลอดภัยของ GitHub Action จึงควรตรึง dependency ด้วยแฮช

    • การใช้แฮชปลอดภัยกว่ามาก

  • GitHub Actions มีปัญหาหลายอย่าง

    • เช่น ข้อจำกัดแคช 10GB, ข้อจำกัด concurrency ตามประเภท runner, ค่าใช้จ่ายสูง เป็นต้น
    • Depot.dev กำลังพยายามทำให้ GitHub Actions เร็วขึ้นและแก้ปัญหาเหล่านี้
    • มันช่วยเร่งการ build Docker image และปรับแต่ง runner ให้เหมาะสม จนทำให้งานต่าง ๆ เร็วมาก
    • GitHub Actions ได้รับความนิยมมาก แต่ก็ยังมีพื้นที่ให้ปรับปรุงอีกมาก