04Jobs · Steps · Runners

บทที่แล้วมี job เดียว pipeline จริงมักมีหลาย job ที่ต้องประสานกัน เข้าใจกฎการทำงานร่วมของ job/step/runner แล้ว คุณจะออกแบบ pipeline ที่ทั้งเร็วและถูกต้องได้

4.1 กฎทองสองข้อ: job ขนาน · step เรียง

นี่คือจุดที่มือใหม่พลาดบ่อยที่สุด ขอย้ำให้ชัด:

• หลาย job รันขนานกันโดยปริยาย และแต่ละ job อยู่บน runner คนละเครื่อง สะอาดแยกกัน — job หนึ่งสร้างไฟล์ไว้ อีก job มองไม่เห็น เพราะคนละเครื่อง
• step ภายใน job เดียวกันรันเรียงกัน บนเครื่องเดียว และ แชร์พื้นที่ทำงาน (workspace) — step แรกติดตั้งของไว้ step ถัดไปใช้ได้ทันที

ผลที่ตามมาในทางปฏิบัติ: งานที่ต้อง "ส่งของต่อกัน" ให้ใส่เป็น step ใน job เดียว ส่วนงานที่อิสระต่อกัน (เช่น เทสต์ frontend กับ backend) ให้แยกเป็นคนละ job จะได้รันพร้อมกัน เร็วขึ้น

4.2 needs — บังคับลำดับเมื่อ job ต้องพึ่งกัน

บางที job ต้องรอกัน เช่น deploy ต้องรอ test ผ่านก่อน ใช้ needs: เพื่อสร้างความสัมพันธ์นั้น — มันเปลี่ยน job ที่เคยขนานให้กลายเป็นกราฟลำดับ (เหมือนสาย commit ในเล่ม Git):

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [ ... รัน linter ... ]
  test:
    runs-on: ubuntu-latest
    steps: [ ... รันเทสต์ ... ]
  build:
    needs: [lint, test]      # รอ lint และ test ผ่านทั้งคู่ก่อน
    runs-on: ubuntu-latest
    steps: [ ... build โปรเจกต์ ... ]

4.3 Runner — เครื่องที่ลงมือทำจริง

Runner คือเครื่อง (จริงหรือเสมือน) ที่รับ job ไปรันจริง มีสองแบบใหญ่ ๆ ซึ่งเราจะลงลึกในบทที่ 13:

• Hosted runner — แพลตฟอร์มเตรียมให้ (เช่น ubuntu-latest, windows-latest) เกิดใหม่สะอาดทุกครั้ง ไม่ต้องดูแล เหมาะกับงานทั่วไป
• Self-hosted runner — เครื่องของคุณเองที่ลงโปรแกรม runner ไว้ ใช้เมื่อต้องการฮาร์ดแวร์พิเศษ (GPU), เข้าถึงเครือข่ายภายใน, หรือคุมค่าใช้จ่าย

✅ สรุปบทที่ 4 — หลาย job รันขนานบน runner แยกเครื่องสะอาด · step ใน job เดียวรันเรียงและแชร์ workspace · needs: สร้างลำดับเมื่อ job ต้องพึ่งกัน และข้าม job ถัดไปถ้าตัวที่พึ่งล้ม · runner มี hosted (สะดวก) และ self-hosted (คุมเอง) · needs คุมลำดับ ไม่ได้ส่งไฟล์ — ส่งไฟล์ข้าม job ต้องใช้ artifact