GitHub Actions cache-mode: ตรวจสอบสิทธิ์แคชที่ซ่อนอยู่เบื้องหลัง CI สีเขียว
หาก CI จบลงด้วยสีเขียวที่ผ่านฉลุย แต่การรันครั้งถัดไปยังคงดาวน์โหลดดีเพนเดนซีใหม่ทั้งหมด เป็นเรื่องง่ายที่เราจะเริ่มแก้จากแคชคีย์ก่อน ทว่าตอนนี้เราต้องตรวจสอบด้วยว่าการบันทึกถูกข้ามไปเนื่องจากสิทธิ์หรือไม่ เพราะความจริงที่ว่าเวิร์กโฟลว์สำเร็จเพียงอย่างเดียว ไม่สามารถยืนยันได้ว่าแคชถูกสร้างขึ้นแล้วจริง
GitHub ได้ประกาศเปิดตัว cache-mode ให้ใช้งานทั่วไป (GA) เมื่อวันที่ 10 กันยายน 2026 โดยทุกแผนบน github.com สามารถกำหนดการเข้าถึงแคชในระดับเวิร์กโฟลว์หรือระดับจ็อบได้ จากบทความก่อนหน้าที่กล่าวถึงค่าเริ่มต้นแบบอ่านอย่างเดียว คราวนี้เราจะเจาะลึกไปที่การตั้งค่าอย่างชัดเจนและวิธีการตรวจสอบความถูกต้อง
ฟีเจอร์ที่ได้รับการยืนยัน: สี่รูปแบบผสมผสานของการกู้คืนและการบันทึก
read อนุญาตเฉพาะการกู้คืน ส่วน write อนุญาตทั้งการกู้คืนและการบันทึก write-only อนุญาตเฉพาะการบันทึก และ none จะบล็อกทั้งสองอย่าง จุดตรวจสอบแรกคืออย่าเข้าใจผิดคิดว่าชื่อ write หมายถึงการบันทึกเท่านั้น
ค่าที่ประกาศไว้ในจ็อบจะมีลำดับความสำคัญเหนือกว่าการตั้งค่าระดับเวิร์กโฟลว์ทั้งหมด ในทางกลับกัน การเรียกใช้เวิร์กโฟลว์ที่ใช้ซ้ำจะไม่สามารถรับสิทธิ์การเข้าถึงที่สูงกว่าระดับที่ผู้เรียกอนุญาตไว้ได้ อย่าตัดสินสิทธิ์ที่แท้จริงของการรันทั้งหมดเพียงแค่อ่านคำประกาศในไฟล์เดียว
การรันที่เป็นสีเขียวไม่ใช่หลักฐานของการบันทึก
เอกสารทางการระบุว่าการดำเนินการเกี่ยวกับแคชที่ไม่ได้รับอนุญาตจะทิ้งบันทึกแจ้งเตือนไว้และดำเนินกระบวนการต่อไป การกู้คืนที่ถูกบล็อกจะถือว่าเป็นแคชมิส และการบันทึกที่ถูกบล็อกจะไม่ถูกดำเนินการ จุดสำคัญในการสังเกตคือตัวเวิร์กโฟลว์เองจะไม่ล้มเหลว
ดังนั้น จึงมีประโยชน์มากกว่าที่จะแยกบันทึกการทำงานออกเป็นสถานะความสำเร็จของการรันและผลลัพธ์ของแคช ให้ตรวจสอบจากการรันครั้งเดียวว่าเหตุการณ์ใดเป็นตัวกระตุ้นการทำงาน ใช้โหมดใด มีการกู้คืนหรือไม่ และการบันทึกถูกข้ามไปหรือไม่ นี่คือแนวทางปฏิบัติในการดำเนินงานที่แนะนำโดยอิงตามคำอธิบายฟังก์ชันอย่างเป็นทางการ ไม่ใช่ฟีเจอร์แดชบอร์ดใหม่ที่ระบบมีให้อัตโนมัติ
สร้างตารางสิทธิ์ขนาดเล็กก่อนนำไปใช้
กางเวิร์กโฟลว์จริงของที่เก็บโค้ดออกมา แล้วค้นหาว่าจ็อบใดเป็นผู้สร้างและจ็อบใดเป็นผู้ใช้แคช จ็อบที่เตรียมดีเพนเดนซีในบรランチที่เชื่อถือได้ จ็อบที่ทดสอบการเปลี่ยนแปลงจากภายนอก และจ็อบที่ตรวจสอบผลลัพธ์การปรับใช้ ไม่จำเป็นต้องผูกมัดด้วยสิทธิ์เดียวกัน
เขียนคำถามสองประโยคสำหรับแต่ละจ็อบ: จ็อบนี้จำเป็นต้องอ่านแคชที่มีอยู่หรือไม่ และสามารถทิ้งผลลัพธ์ของจ็อบนี้ไว้ให้การรันครั้งต่อไปอ่านได้หรือไม่ หากไม่จำเป็นทั้งสองอย่าง คุณอาจเริ่มทบทวนความเคยชินในการใส่แคชใหม่ตั้งแต่แรกได้ อย่างไรก็ตาม การตั้งค่าจริงควรตัดสินใจตามขอบเขตความน่าเชื่อถือและโครงสร้างการบิลด์ของที่เก็บโค้ด
การทดลองขั้นต่ำ: จ็อบผู้ใช้แบบอ่านอย่างเดียว
ตัวอย่างเช่น ในเวิร์กโฟลว์สำหรับการทดสอบ ให้ระบุ cache-mode: read ไว้ที่ระดับบนสุด และตรวจสอบให้แน่ใจว่าไม่มีการเขียนทับในระดับจ็อบ เปรียบเทียบผลการทดสอบเมื่อใช้แคชกับผลการทดสอบเมื่อไม่มีแคชว่าเหมือนกันหรือไม่ แคชควรเป็นเพียงเครื่องมือเสริมในการลดเวลาการรัน ดังนั้นหากความถูกต้องเปลี่ยนแปลงไปเมื่อไม่มีแคช คุณควรตรวจสอบสมมติฐานของการบิลด์เป็นอันดับแรก
เกณฑ์ผ่านสำหรับการทดลองนี้ไม่ใช่แค่บรรทัดความสำเร็จของ CI บรรทัดเดียว แต่คุณต้องสามารถอธิบายความพยายามในการกู้คืนและการข้ามการบันทึกได้ รวมถึงสามารถตรวจสอบซ้ำด้วยอินพุตเดิมในการรันครั้งถัดไปได้ การบันทึกคอมมิตก่อนและหลังการทดลอง ทริกเกอร์ การตั้งค่าที่มีผล และตำแหน่งของบันทึกควบคู่กัน จะช่วยให้เพื่อนร่วมงานสามารถจำลองการตัดสินใจได้ง่ายขึ้น
เวิร์กโฟลว์ที่ใช้ซ้ำต้องอ่านไปถึงเส้นทางการเรียก
แม้ว่าคุณจะใส่ค่าเริ่มต้นที่ปลอดภัยไว้ในเวิร์กโฟลว์ส่วนกลางแล้ว แต่คุณยังต้องตรวจสอบทั้งฝั่งผู้เรียกและการตั้งค่าของแต่ละจ็อบร่วมกัน ความจริงที่ว่าแต่ละที่เก็บโค้ดเรียกไฟล์เดียวกัน ไม่ได้หมายความว่าจะทำงานด้วยสิทธิ์เดียวกัน
ในระหว่างการตรวจสอบโค้ด ให้ลองไล่ตามลำดับตั้งแต่ผู้เรียก คำประกาศแคชของจ็อบ ไปจนถึงเวิร์กโฟลว์ที่ถูกเรียก หากสิทธิ์ที่คาดหวังกับบันทึกจริงไม่ตรงกัน ให้ค้นหาต้นตอของการตั้งค่าก่อนที่จะทำให้คีย์ซับซ้อนขึ้น นี่เป็นข้อเสนอแนะเพื่อลดเวลาในการวินิจฉัยสำหรับองค์กรที่มีการใช้ซ้ำเป็นจำนวนมาก และไม่ได้หมายถึงตัวเลขประสิทธิภาพที่วัดได้แน่นอน
ข้อยกเว้นที่ต้องระวังและลำดับขั้นตอนการนำไปใช้
หากคุณระบุ write หรือ write-only ให้กับเหตุการณ์ที่มีความน่าเชื่อถือต่ำ เช่น pull_request_target การตั้งค่านี้อาจแทนที่ข้อจำกัดเริ่มต้นแบบอ่านอย่างเดียวและเพิ่มความเสี่ยงของการปนเปื้อนแคชได้ ซึ่ง GitHub จะเพิ่มคำอธิบายเตือนในกรณีนี้ คุณควรหลีกเลี่ยงการตอบสนองด้วยการเพิ่มสิทธิ์การเขียนเพียงเพื่อกำจัดคำเตือน
ในทางกลับกัน การเลือกบล็อกแคชทั้งหมดก็มีต้นทุนเช่นกัน เวลาในการดาวน์โหลดและการบิลด์อาจเพิ่มขึ้น ดังนั้นควรเปรียบเทียบเวลารันจริงในจ็อบตัวแทนหนึ่งจ็อบก่อนที่จะขยายขอบเขต อย่าสัญญาเรื่องผลลัพธ์ด้านประสิทธิภาพโดยการคาดเดาตัวเลข แต่ควรให้ทีมร่วมกันกำหนดข้อจำกัดที่จำเป็นด้านความปลอดภัยและความล่าช้าที่ยอมรับได้
คำถามที่ทีมควรตรวจสอบในตอนนี้
สิ่งที่คุณควรทำในวันนี้ไม่ใช่การเพิ่มการตั้งค่าใหม่ลงในทุกที่เก็บโค้ดพร้อมกันทั้งหมด แต่เป็นการค้นหาผู้สร้างและผู้ใช้แคชในหนึ่งเวิร์กโฟลว์สำคัญ กำหนดสิทธิ์ลงไป และตรวจสอบหลักฐานของการกู้คืนและการบันทึกจากการรันหนึ่งครั้ง หากเป็นจ็อบการปรับใช้ ให้รักษาการเปลี่ยนแปลงให้มีขนาดเล็ก เพื่อให้ผู้รับผิดชอบสามารถอ่านบันทึกและตรวจสอบว่าตรงกับที่คาดไว้หรือไม่
คำถามที่อาจเกิดขึ้นในการทำงานจริงคือ ทำไม CI จึงสำเร็จทั้งที่ขั้นตอนการบันทึกถูกข้ามไป บทความนี้อธิบายความสับสนดังกล่าวตามการทำงานอย่างเป็นทางการ โดยไม่ได้อ้างอิงถึงผลสำรวจชุมชนแยกต่างหากหรืออัตราการเกิดข้อผิดพลาดทั่วไป เมื่อนำฟีเจอร์ใหม่มาใช้ การตรวจสอบทั้งผลลัพธ์ด้านประสิทธิภาพและผลลัพธ์ด้านสิทธิ์แยกจากกัน จะช่วยให้คุณจำแนกปัญหาแคชในครั้งต่อไปได้อย่างแม่นยำยิ่งขึ้น