Actions lockfile เปิดใช้ทั่วไปแล้ว: เครื่องหมายเขียวพิสูจน์อะไรบ้าง
PR อาจแสดงเวอร์ชัน uses เดิม แต่โค้ดที่อยู่เบื้องหลังเปลี่ยนไปได้ เพราะ tag ย้ายไปชี้ commit อื่นได้ GitHub ประกาศให้ workflow lockfile ใช้งานทั่วไปเมื่อ 28 ตุลาคม หลังช่วงพรีวิว สิ่งที่ควรเข้าใจต่อคือการตรวจแต่ละแบบให้หลักฐานอะไร
ชื่ออ้างอิงอ่านง่าย แต่รัน commit ที่บันทึกไว้
.github/workflows/actions.lock เชื่อมชื่ออ้างอิง action กับ commit ที่จะรัน สร้างด้วย gh actions-lock และรองรับ Free, Team และ GitHub Enterprise Cloud รวมสภาพแวดล้อม data residency ทยอยนำเข้าได้ทีละ workflow โดยรีวิวไฟล์ที่สร้างพร้อมการเปลี่ยน workflow ไม่ประกอบ lockfile ด้วยมือ
สมมติ demo/build@v1 ชี้ A ก่อนย้ายไป B ถ้าอาศัยชื่ออ้างอิงอย่างเดียว การรันครั้งหน้าอาจเลือกโค้ดใหม่ แต่ lockfile เลือก commit ที่บันทึกไว้ ภาพเป็นตัวอย่างสมมติ ไม่ใช่ผลทดสอบจริง หาก commit เข้าถึงไม่ได้จาก tag หรือ branch ที่บันทึกไว้ ระบบอาจปฏิเสธเมื่อรัน
ผ่านการตรวจออฟไลน์หมายถึงอะไร
gh actions-lock --verify-local ตรวจ coverage โดยไม่ใช้เครือข่าย ว่ามีรายการสำหรับ uses หรือไม่ เหมาะกับก่อน commit แต่ไม่ได้ตรวจที่มาของโค้ด ส่วน gh actions-lock --verify ตรวจ provenance ออนไลน์ และ runner ตรวจซ้ำเมื่อ job เริ่ม ผลเขียวสองแบบจึงมีความหมายต่างกัน
ถ้า PR อีกชุดเพิ่ม action แต่ลืมอัปเดต lockfile การตรวจในเครื่องอาจพบรายการที่ขาดได้ อย่างไรก็ตาม รายการครบไม่ได้พิสูจน์ที่มาหรือความปลอดภัยของโค้ด ภาพที่สองสรุปขอบเขตจากเอกสาร บทความนี้ไม่ได้ติดตั้งหรือรัน CLI จริง
reusable workflow มีขอบเขต repository ของตัวเอง
การอ้างอิง action ทางอ้อมอยู่ในขอบเขต แต่การเรียก reusable workflow ผ่าน jobs.<job_id>.uses ไม่ได้ถูกตรึงด้วย lockfile ต้องระบุ SHA เต็มของ commit ส่วน action ภายในใช้ lockfile ของ repository ที่นิยาม workflow ไม่ใช่ฝั่งผู้เรียก
สมมติ repository แอปเรียก deployment ของ repository แพลตฟอร์ม ดู actions.lock ของแอปอย่างเดียวจะไม่เห็น commit ของ action ฝั่งแพลตฟอร์ม ต้องอ่าน SHA ที่เรียกคู่กับการเปลี่ยน dependency ฝั่งนั้นด้วย image ของ runner, input และ secret ก็ยังเป็นคนละส่วน การตรึง action ไม่ได้ตรึงทั้งสภาพแวดล้อม
อ่านสองไฟล์ควบคู่ใน PR อัปเดต
เมื่อ Dependabot อัปเดตเวอร์ชัน action ของ workflow ที่นำเข้าระบบแล้ว จะสร้างรายการ lockfile ที่เกี่ยวข้องใหม่ใน PR เดียวกัน จึงเปรียบเทียบเวอร์ชันอ่านง่ายกับ commit จริงได้ ส่วน --relock เลื่อน reference และเขียนไฟล์ ต่างจากการตรวจแบบอ่านอย่างเดียว ยังต้องรีวิวโค้ดที่เปลี่ยน
Require lockfile บังคับการใช้งานได้ แต่ไม่ได้ลบขอบเขต repository เริ่มจาก workflow เดียวช่วยให้เข้าใจกระบวนการสร้าง รีวิว และตรวจออนไลน์ เมื่อเห็นเครื่องหมายเขียวครั้งหน้า ควรอ่านให้ชัดว่าเป็นหลักฐานเรื่องรายการครบ ที่มาถูกต้อง หรือการรีวิวโค้ดที่เลือก