การเปลี่ยนผ่านสู่ Ubuntu 26.04 ใน GitHub Actions: เริ่มต้นด้วยการตรวจสอบความแตกต่างของรันเนอร์ด้วยคอมมิตเดียวกัน
แม้ไม่ได้แก้ไขซอร์สโค้ด แต่ผลลัพธ์ของ CI ก็อาจเปลี่ยนแปลงได้ หากเวิร์กโฟลว์ของคุณพึ่งพา ubuntu-latest สำหรับสภาพแวดล้อมการทำงาน การเปลี่ยนผ่านของอิมเมจระบบปฏิบัติการก็ควรเป็นหนึ่งในการเปลี่ยนแปลงที่ทีมต้องคอยจัดการดูแล
GitHub ได้ประกาศแผนการรองรับรันเนอร์ Ubuntu 26.04 อย่างเป็นทางการและการเปลี่ยนผ่านของ ubuntu-latest เมื่อวันที่ 17 กันยายน 2026 บทความนี้ไม่ได้มาเพื่อบอกว่าอิมเมจใหม่จะเร็วกว่าเสมอไป แต่เป็นข้อเสนอแนะเชิงปฏิบัติในการแยกแยะและตรวจสอบความแตกต่างของสภาพแวดล้อมโดยใช้คอมมิตเดียวกัน
ขอบเขตที่ได้รับการยืนยันจากประกาศอย่างเป็นทางการ
ตามประกาศดังกล่าว อิมเมจ Ubuntu 26.04 จะได้รับการรองรับอย่างเป็นทางการทั้งบน x64 และ arm64 โดยมีเลเบลที่ระบุอย่างชัดเจนคือ ubuntu-26.04 และ ubuntu-26.04-arm ส่วน ubuntu-latest มีกำหนดการทยอยปรับเปลี่ยนจาก Ubuntu 24.04 ไปเป็น 26.04 อย่างค่อยเป็นค่อยไประหว่างวันที่ 19 ตุลาคม ถึง 19 พฤศจิกายน 2026
อิมเมจใหม่มีการอัปเดตหรือลบเครื่องมือบางส่วนออกไป ซึ่งอาจส่งผลกระทบต่อบิลด์ที่ต้องพึ่งพาแพ็กเกจที่ติดตั้งไว้ล่วงหน้า GitHub แนะนำให้ระบุเป็น ubuntu-24.04 อย่างชัดเจนหากยังเตรียมการไม่พร้อม ทั้งนี้ กำหนดการนี้ไม่ได้หมายถึงวันที่เปลี่ยนผ่านจริงของทุกที่เก็บโค้ด (Repository)
บันทึกสภาพแวดล้อมที่ที่เก็บโค้ดของเราคาดหวัง
ขั้นแรก ให้ตรวจสอบ runs-on ในเวิร์กโฟลว์และเวิร์กโฟลว์ที่ใช้ซ้ำ (Reusable Workflows) อย่าเพิ่งสันนิษฐานว่าการใช้คอนเทนเนอร์จะทำให้ผลกระทบจากโฮสต์หมดไป และควรอ่านไปจนถึงขั้นตอนการติดตั้ง การบีบอัดไฟล์ และการอัปโหลดที่ทำงานนอกคอนเทนเนอร์ด้วย
ลองแบ่งหมวดหมู่ในเช็กลิสต์โดยแยกเป็นคอมไพเลอร์, รันไทม์, ตัวจัดการแพ็กเกจ และไลบรารีของระบบ แทนที่จะจดเพียงแค่ชื่อเครื่องมือ การระบุเชื่อมโยงว่าเครื่องมือนั้นติดตั้งมาจากที่ใดและขั้นตอนใดเป็นผู้เรียกใช้ จะช่วยให้จำกัดสาเหตุในบันทึกข้อผิดพลาด (Failure logs) ได้ง่ายขึ้น
คอมมิตเดียวกัน สองสภาพแวดล้อม และ Artifact ที่แยกจากกัน
การซ้อมเปลี่ยนผ่านควรเริ่มต้นบนเส้นทางการทดสอบที่ไม่มีสิทธิ์ในการปรับใช้ (Deploy) เพื่อความชัดเจนและปลอดภัย ให้รันคอมมิตเดียวกันและล็อกไฟล์เดียวกันบนทั้งอิมเมจเดิมและอิมเมจใหม่ พร้อมทั้งแยกเก็บรักษาบันทึก (Logs), ผลการทดสอบ และชื่อของ Artifact ไว้อย่างเป็นอิสระต่อกัน นี่คือแนวทางการตรวจสอบที่บทความนี้แนะนำ
ในการเปรียบเทียบเบื้องต้น ให้บันทึกเงื่อนไขของแคชไว้เพื่อแยกแยะผลกระทบจากแคชเก่า นอกจากสถานะความสำเร็จของบิลด์แล้ว ควรบันทึกเวอร์ชันของเครื่องมือที่ติดตั้ง ขั้นตอนที่ล้มเหลว และผลการรัน Artifact เอาไว้ด้วย เพื่อแยกความแตกต่างของผลลัพธ์ที่ผ่านได้โดยบังเอิญจากการที่แคชทำงานตรงเป้า (Cache hit)
การตรวจสอบที่ยังคงอยู่หลังเครื่องหมายถูกสีเขียว
หากเป็นโปรเจกต์เว็บ คุณสามารถตรวจสอบได้ว่าไฟล์ที่สร้างขึ้นสามารถนำไปให้บริการจริงได้หรือไม่ หรือหากมี Native Dependencies ก็ควรตรวจดูว่าสามารถโหลดในสภาพแวดล้อมเป้าหมายได้หรือไม่ แทนที่จะยึดกฎว่าทุกไบต์ของ Artifact ต้องเหมือนกันทุกประการ ให้แยกแยะความแตกต่างที่ไม่แน่นอน (Non-deterministic differences) เช่น ไทม์สแตมป์ ออกจากความแตกต่างด้านการทำงาน
ผู้ตรวจสอบควรจะสามารถดูลิงก์การรันบนอิมเมจใหม่, ความแตกต่างของเวอร์ชันเครื่องมือ, ผลการตรวจสอบฟังก์ชันหลัก และการเปลี่ยนแปลงที่ต้องย้อนกลับได้จากที่เดียว การรวมการรีแฟกเตอร์แอปพลิเคชันเข้ากับการเปลี่ยนผ่านรันเนอร์ จะทำให้ขอบเขตการย้อนกลับและสาเหตุความล้มเหลวกว้างเกินความจำเป็น
ข้อดีของการตรึงอิมเมจและข้อจำกัดที่ยังคงมีอยู่
การใช้เลเบลระบบปฏิบัติการแบบระบุชัดเจนช่วยให้ควบคุมการเปลี่ยนแปลงครั้งใหญ่ได้ แต่ไม่ได้หมายถึงสภาพแวดล้อมบิลด์ที่ไม่เปลี่ยนแปลงอย่างแท้จริง ควรคงนิสัยในการติดตั้งเครื่องมือที่จำเป็นต่อการรันอย่างชัดเจน และบันทึกเวอร์ชันจริงลงในบันทึกควบคู่ไปด้วย
สำหรับที่เก็บโค้ดขนาดเล็ก ไม่จำเป็นต้องสร้างระบบตรวจสอบขนาดใหญ่ขึ้นมาใหม่ คุณสามารถเริ่มต้นได้ด้วยการเปรียบเทียบบิลด์ตัวแทนสักหนึ่งตัวและดีเพนเดนซีที่เปราะบางที่สุด และหากมีการตรึงเวอร์ชันไว้ชั่วคราว ก็ให้ระบุผู้รับผิดชอบในการปลดล็อกและกำหนดวันที่ที่จะทบทวนร่วมกันไว้ด้วย
แยกการอภิปรายสาธารณะออกจากการตัดสินใจของทีมเรา
คลังประเด็นปัญหา (Issues) สาธารณะของ runner-images เป็นช่องทางสำหรับตรวจสอบการเปลี่ยนแปลงของอิมเมจและการรายงานปัญหา แต่ความคิดเห็นบางรายการหรือความล้มเหลวของโปรเจกต์อื่นไม่ได้หมายความว่าจะเกิดขึ้นกับที่เก็บโค้ดของเราเสมอไป และบทความนี้ไม่ได้อ้างอิงถึงฉันทามติของชุมชนหรือความถี่ของข้อผิดพลาดในเชิงตัวเลข
สิ่งที่คุณควรทำในวันนี้คือการค้นหาจุดที่มีการใช้เลเบล latest และทดสอบคอมมิตเดียวกันบนอิมเมจใหม่ หากระบุเงื่อนไขการผ่านและเงื่อนไขการระงับไว้ล่วงหน้า แม้ว่าบิลด์จะเปลี่ยนแปลงไปในช่วงเวลาเปลี่ยนผ่านจริง ผู้รับผิดชอบก็จะสามารถตัดสินใจโดยใช้หลักฐานเดียวกันได้