GitHub Actions: คอมมิตที่ล็อกไว้ก็ต้องตรวจทาน
ถ้า workflow ที่ตรวจแล้วภายหลังรันโค้ดอื่น เราอนุมัติอะไรไป GitHub ประกาศพรีวิวสาธารณะของ lockfile เมื่อ 14 ตุลาคม ต้องกำหนดว่าใครตรวจคอมมิตและใครอนุมัติการอัปเดตครั้งต่อไป
ตรวจขอบเขตก่อน
ประกาศที่แก้ไขครอบคลุม GitHub Enterprise Cloud, Enterprise Cloud แบบ data residency, Team และ Free ยังเป็นพรีวิว รีโพทางการระบุว่าไม่รองรับ GHES และอาจเปลี่ยนก่อน 1.0 จดวันที่และรุ่นส่วนขยายไว้
แยกแท็กออกจากคอมมิตที่อนุมัติ
ส่วนขยายสร้าง .github/workflows/actions.lock บันทึกคอมมิตของ action การพึ่งพาทางอ้อม และ workflow ที่เรียกใช้ซ้ำของ workflow ที่เข้าร่วม ลดการเปลี่ยนโค้ดเงียบเมื่อ ref ขยับ แต่ไม่ได้รับรองว่าโค้ดที่ล็อกปลอดภัย
เริ่มจากการเปลี่ยนแปลงเล็กที่ตรวจได้
ข้อเสนอการทำงาน: เลือก workflow ทดสอบที่ไม่มีความลับ production หรือสิทธิ์ deploy ทำรายการ uses เจ้าของ และวัตถุประสงค์ ตรวจ workflow กับ lockfile ใน PR เดียว แล้วเชื่อมกับการรันจริงก่อนบังคับใช้วงกว้าง
กำหนดผู้ดูแลอัปเดต
README ระบุ gh actions-lock --verify ว่าตรวจโดยไม่เขียนไฟล์ ส่วน --verify-local ตรวจโครงสร้างออฟไลน์ ไม่แทนการตรวจความน่าเชื่อถือ แยกผล CI กับการรีวิวโค้ด กำหนดผู้รับผิดชอบ จุดหยุด และการกู้คืน บทความนี้ไม่ได้ติดตั้งส่วนขยาย
ตามประกาศ Dependabot สร้างรายการ lockfile ที่เกี่ยวข้องใหม่ใน PR เดียวเมื่ออัปเดต action ที่เข้าร่วม diff อัตโนมัติก็ต้องตรวจ ข้อเสนอคือเทียบ ref คอมมิต สิทธิ์ และการสื่อสารภายนอกของโค้ดใหม่
การทำซ้ำได้ไม่ใช่คำตัดสินความปลอดภัย การร่วมให้ข้อเสนอแนะของชุมชนไม่ได้พิสูจน์อัตราลดเหตุหรือความเข้ากันได้ทุกระบบ อ่าน README ปัจจุบันและกำหนดเจ้าของการตรวจ การล็อก และการอัปเดต
แหล่งทางการ
ตรวจวันที่ 15 ตุลาคม 2026 แยกข้อเสนอการทำงานจากคุณสมบัติผลิตภัณฑ์