ดูแลให้ทำงานต่อเนื่อง
เมื่อ build ล้มเหลว — และ log กำลังบอกอะไร
การนำขึ้นออนไลน์ที่ล้มเหลวจะคืนสาเหตุกลับมา ไม่ใช่ผลลัพธ์ทั้งกำแพง ความล้มเหลวสี่แบบครอบคลุมเกือบทั้งหมด และหนึ่งในสี่นั้นไม่พิมพ์อะไรออกมาเลย — ซึ่งเป็นจังหวะที่การดู log ท้ายๆ บอกอะไรได้น้อยที่สุดพอดี
ดูที่ไหน
รุ่นที่ล้มเหลวจะพกสาเหตุไว้ตรงนั้น เอไอของคุณอ่านสิ่งเดียวกัน เพราะแบบนี้การพูดว่า "มันล้มเหลว ช่วยแก้ที" จึงมักเพียงพอแล้ว
1. หน่วยความจำไม่พอ
แบบที่ดูเหมือนไม่มีอะไรเกิดขึ้น การ build ถูก kernel ฆ่าก่อนที่จะได้เขียนอะไรลงไป log สามสิบบรรทัดสุดท้ายจึงว่างเปล่าในจังหวะที่คุณต้องการมันที่สุด เอราวัณจึงรายงาน exit code แทน — 137 — และบอกเป็นคำพูด เพราะ "log ว่างเปล่า" กับ "build ถูกฆ่า" หน้าตาเหมือนกันแต่เป็นคนละปัญหา
ส่วนใหญ่มาจาก bundler บนโปรเจกต์ขนาดใหญ่ ลดสิ่งที่ build ต้องโหลด หรือเลื่อนแพ็กเกจขึ้น
2. ไฟล์ที่ Dockerfile จะคัดลอกไม่มีอยู่จริง
แบบนี้ซ่อนตัว BuildKit รายงานว่า failed to compute cache key พร้อมรหัสอ้างอิงสองก้อนที่อ่านไม่รู้เรื่องอยู่หน้าชื่อไฟล์ ซึ่งอ่านแล้วเหมือนเป็นความผิดของเรา ระบบจึงดึงชื่อไฟล์ออกมาไว้หน้าสุด — เกือบทุกครั้งคือ path ใน COPY ที่สะกดไม่ตรงกับไฟล์จริง หรือถูก .dockerignore กันออกไป
3. dependency ติดตั้งไม่ได้
เวอร์ชันที่ไม่มีอยู่จริง แพ็กเกจที่เปลี่ยนชื่อ lockfile ที่มาจากคนละแพลตฟอร์ม บรรทัดที่ล้มจะถูกยกมาพร้อมส่วนท้ายต่อจากนั้น แบบนี้ควรส่งกลับให้เอไอของคุณตรงๆ เพราะมันเป็นคนเขียนรายการ dependency และมันอ่าน error นั้นได้
4. build แล้วไม่ได้ไฟล์อะไรเลย
เกิดกับเว็บไซต์ ไม่ใช่บริการ npm run build จบอย่างราบรื่นแต่ไม่ได้เขียนอะไรในที่ที่เราไปดู — dist, build, out, public, .output/public ส่วนใหญ่คือ build ที่ตั้งค่าให้ออกไฟล์ไว้ที่อื่น
ทำไมได้ข้อความเดียว ไม่ใช่ log ทั้งกอง
BuildKit พิมพ์ความล้มเหลวเดียวกันสองครั้ง — ครั้งแรกเป็นขั้นตอนที่ล้ม อีกครั้งเป็น solve error ข้างใต้ ถ้าคืนดิบๆ มันอ่านเหมือนมีสองปัญหา และส่งคนแก้ไปตามหาสาเหตุที่สองที่ไม่มีอยู่ การพูดครั้งเดียวพร้อมส่วนท้ายต่อท้าย คือความต่าง
เวอร์ชันที่รันอยู่ไม่ถูกแตะ
build ที่ล้มเหลวไม่เปลี่ยนอะไรเลย รุ่นที่ออนไลน์อยู่ยังออนไลน์ และยังตอบทุกคำขอระหว่างที่คุณแก้ — การนำขึ้นออนไลน์ที่ล้มเหลวคิดค่าเสียหายเป็นเวลารอเท่านั้น