06Artifacts & Caching

สองคำนี้คือ "fetch กับ pull" แห่งโลก CI/CD — ฟังดูคล้ายกันจนคนสับสนตลอด แต่จุดประสงค์ต่างกันสิ้นเชิง เข้าใจเส้นแบ่งนี้แล้ว pipeline ของคุณจะทั้งเร็วขึ้นและส่งของต่อกันได้ถูกต้อง

6.1 Artifact — ผลงานที่ต้องส่งต่อ

จำกับดักจากบทที่ 4: job คนละเครื่อง ส่งไฟล์หากันเองไม่ได้ artifact คือสะพานนั้น — job build "upload" ผลลัพธ์ (เช่นโฟลเดอร์ dist/ หรือไฟล์ .jar) ขึ้นที่เก็บกลาง แล้ว job deploy "download" กลับลงมาใช้ artifact เป็น ของที่มีคุณค่า ต้องเก็บไว้ใช้ต่อ และมักดาวน์โหลดมาดูภายหลังได้ด้วย

# ใน job build — อัปโหลดผลลัพธ์
- uses: actions/upload-artifact@v4
  with:
    name: dist
    path: dist/
# ใน job deploy — ดาวน์โหลดกลับมา
- uses: actions/download-artifact@v4
  with:
    name: dist

6.2 Cache — ความเร็วที่ทิ้งได้

การติดตั้ง dependencies (npm, pip, Maven) ซ้ำทุกครั้งเสียเวลามาก ทั้งที่มันแทบไม่เปลี่ยน cache แก้ตรงนี้: เก็บโฟลเดอร์ที่ "สร้างใหม่ได้" (เช่น node_modules/) ไว้ใช้ซ้ำในการรันครั้งหน้า ต่างจาก artifact ตรงที่ cache หายได้โดยไม่กระทบความถูกต้อง — แค่ทำให้ช้าลง pipeline ก็ยังรันได้เหมือนเดิม

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}   # key เปลี่ยนเมื่อ lock เปลี่ยน

เคล็ดอยู่ที่ cache key: ผูกกับ hash ของไฟล์ lock — ถ้า dependencies ไม่เปลี่ยน key เดิม ใช้ cache เดิม เร็วปรู๊ด; ถ้า lock เปลี่ยน key เปลี่ยน CI สร้าง cache ใหม่ให้ ไม่มีทางใช้ของเก่าผิดเวอร์ชัน

✅ สรุปบทที่ 6 — artifact = ส่ง "ผลงานที่ต้องใช้ต่อ" ข้าม job (build→deploy) ถ้าหาย pipeline พัง · cache = เก็บ "ของที่สร้างใหม่ได้" (deps) ไว้ใช้ซ้ำข้ามการรันเพื่อความเร็ว ถ้าหายแค่ช้าลง · cache key ผูกกับ hash ของ lock file เพื่อกันใช้ของเก่าผิดเวอร์ชัน