GitHub Actions Workflow Generator: สร้าง workflow CI ที่ใช้งานได้จริงในไม่กี่นาที

workflow YAML สำหรับ CI ที่ดีมี boilerplate เป็น 80% — generate มาก่อน แล้วค่อยปรับเอง ทั้ง block on:, การ setup Node.js, dependency cache, ขั้นตอน lint-test-build, การ login และ push ผ่าน Docker เกือบทุก repository ฝั่ง JavaScript ต้องใช้โครงแบบเดียวกัน แต่ทีมส่วนใหญ่กลับประกอบมันด้วยการ copy จากโปรเจกต์เก่าหรือ tutorial ที่ติด action เวอร์ชันเก่าหลายปี ส่วนที่สำคัญจริง ๆ อีก 20% — trigger ไหนทำงาน, ทดสอบ Node เวอร์ชันใด, push อะไรไปที่ไหน — กลับถูกฝังอยู่ใต้งานประปาที่คุณพิมพ์มาหลายสิบรอบแล้ว

GitHub Actions Workflow Generator ยุบปัญหานี้ลงเหลือฟอร์มสั้น ๆ เลือก trigger ที่ต้องการ (push, pull request, dispatch ด้วยมือ หรือ cron), เลือก version matrix ของ Node.js, เปิด dependency cache, สลับขั้นตอน lint, test และ build ที่โปรเจกต์รันจริง และถ้าต้องการ เพิ่ม job Docker ที่ push image ไป ghcr.io เครื่องมือจะสร้าง workflow YAML ฉบับสมบูรณ์ตามตัวเลือกเหล่านั้น พร้อมเอาไปวางใน .github/workflows/ ได้ทันที

ทุกอย่างทำงาน 100% ใน browser: ไม่ต้องมี account ไม่ต้อง upload — YAML ถูก generate ในเครื่องคุณเป็นข้อความล้วน ๆ

ทำไมต้องใช้ GitHub Actions Workflow Generator

• ได้โครงที่สอดคล้องกัน ไม่ใช่ไฟล์เปล่า — trigger, matrix, cache และ step มาพร้อมกันอย่างถูกต้อง คุณแก้ค่า ไม่ใช่ออกตามหา needs: ที่หายไป
• action เป็นเวอร์ชันปัจจุบันตั้งแต่ต้น — checkout, setup-node และ cache เป็นเวอร์ชันที่ดูแลอยู่ ไม่ใช่ snippet ตกทอดจาก repo เก่า
• matrix เป็นทางเลือก ไม่ใช่งานหนัก — ทดสอบ Node.js 18, 20 และ 22 ได้ด้วย toggle เดียว ไม่ต้อง refactor block strategy ด้วยมือ
• cache มาให้โดยไม่ต้องพิถีพิถัน — cache step และ lockfile key ปรากฏให้เอง ซึ่งคือ speedup ที่ pipeline ส่วนใหญ่ขาด
• Docker ไป ghcr.io เมื่อคุณต้องการ — job deploy มาพร้อม login, build และ push ที่ registry, tag และ permission สอดคล้องกันตั้งแต่แรก
• เป็นส่วนตัวตั้งแต่การออกแบบ — เป็น client-side JavaScript ล้วน รายละเอียด pipeline ของโปรเจกต์จึงไม่มีวันไปแตะบริการภายนอก

ฟีเจอร์หลัก

YAML ที่ได้เรียงตามลำดับที่คน review อ่าน — name, trigger, permission แล้ว job — และค่าที่เกี่ยวข้องกันขยับพร้อมกัน การเปิด job Docker จะปรับ dependency และ permission ของ job ให้ด้วย ไฟล์จึงสอดคล้องภายในตัวเองโดยไม่มี templating syntax ให้ต้องเรียนรู้

วิธีใช้งาน

1. เปิด GitHub Actions Workflow Generator แล้วเลือก trigger ที่โปรเจกต์ต้องการ — ส่วนใหญ่เริ่มที่ push กับ pull_request
2. เลือกเวอร์ชัน Node.js สำหรับ matrix — ให้ตรงกับที่แอปรองรับ ไม่ใช่ทุกเวอร์ชันที่มีอยู่
3. เปิด dependency cache แล้วสลับขั้นตอน lint, test และ build ให้ตรงกับ script ใน package.json
4. ถ้าส่ง container เปิด job Docker deploy ไป ghcr.io แล้วแก้ชื่อ image ให้ตรงกับ repository
5. ตรวจ YAML, copy หรือ download เป็น ci.yml ลง .github/workflows/, commit แล้วดูรอบแรกในแท็บ Actions

ชิ้นส่วนสำคัญของ workflow ที่ generate ได้

Trigger ใน on: — แต่ละตัวมีเหตุผลของตัวเอง push รัน pipeline เมื่อ commit มาถึง ควรกั้นด้วย filter branches: [main] เพื่อไม่ให้ feature branch ทำงานซ้ำสองเท่า pull_request คือจุดที่ CI ให้คุณค่ามากที่สุด เพราะตรวจ diff ก่อน merge workflow_dispatch เพิ่มปุ่ม Run workflow แบบ manual ใช้ได้ทั้งตอน release และตอนทดสอบการแก้ pipeline schedule รับ cron expression แล้วรันเป็นรอบเวลา เครื่องมือเขียน block เหล่านี้ด้วยการ nesting และ quoting ที่ถูกต้อง — ตรงจุดที่คนเขียนมือพลาดบ่อยที่สุด

Node.js matrix strategy — แทนการ hardcode เวอร์ชันเดียว matrix จะประกาศ list ใต้ strategy.matrix.node แล้ว GitHub แตก job ออกเป็นหนึ่งชุดต่อหนึ่งเวอร์ชัน วิธีนี้จับ bug คลาสสิกที่โค้ดรันได้บน Node 22 แต่พังเงียบ ๆ บน Node 18 ที่ลูกค้ายังใช้อยู่ มีปุ่มสองตัวที่ควรรู้ fail-fast (เปิดอยู่แล้วตามค่าเริ่มต้น) จะยกเลิก job ที่เหลือเมื่อตัวหนึ่งพัง ส่วน max-parallel จำกัดจำนวน job พร้อมกัน สามเวอร์ชัน — เพดานต่ำสุดที่รองรับ, เวอร์ชันที่ทีมใช้ develop และเวอร์ชันล่าสุด — คือจุดสมดุลที่ดีที่สุด

actions/cache สำหรับ node_modules — cache step จะ hash lockfile เป็น key แล้ว restore node_modules หรือ store ของ package manager เมื่อ key ตรงกับรอบก่อน npm ci เย็น ๆ ใช้เวลาเป็นนาที แต่เมื่อ cache hit ใช้เวลาเป็นวินาที เพราะ hash ของ lockfile เป็นส่วนหนึ่งของ key การเพิ่มหรืออัปเกรด dependency จะรีเซ็ต cache ตามดีไซน์ แล้วเก็บ install ที่สดและถูกต้องเข้าไปแทน เครื่องมือจับ cache step คู่กับ input cache: ในตัวของ actions/setup-node ซึ่งเป็นรูปแบบยุคใหม่ที่สั้นกว่า

ลำดับ job: lint แล้ว test แล้ว build แล้ว Docker — pipeline รันเป็นโซ่ needs: ตามลำดับที่ตั้งใจไว้ lint พังเร็วที่สุด — เป็นวินาที ไม่ใช่นาที — จึงไม่มี formatting เสียต้องจ่าย install สองรอบ test ตามมาบน matrix เพราะเป็นด่านที่แพงที่สุดและคู่ควรกับการรันขนาน build รันเมื่อ test เขียว แล้วผลิต artifact ที่ image ต้องใช้ ส่วน Docker ประกาศ needs: build image จึงไม่มีวันถูก push จากโค้ดที่ไม่ผ่าน

GITHUB_TOKEN และสุขอนามัยของ secrets สำหรับ ghcr — การ push ขึ้น GitHub Container Registry ไม่ต้องใช้ personal access token: GITHUB_TOKEN แบบ scope ระดับ workflow ยืนยันตัวได้ ขอให้ job ประกาศ permissions: packages: write เครื่องมือกำหนดสิทธิ์นี้เฉพาะ job Docker เท่านั้น — least privilege อย่าเอา PAT ไปวางในไฟล์ workflow และอย่าขยาย permission เพื่อแก้ error ของ registry ส่วน registry ภายนอกให้เก็บ credential เป็น repository secret แล้วอ้างด้วยชื่อ

ตัวอย่างผลลัพธ์พร้อมคำอธิบาย:

name: CI
on:
  push:
    branches: [main] # ทุกการ merge เข้า main ไม่ใช่ทุก branch
  pull_request: # ตรวจ diff ก่อนมันรวมเข้า
  workflow_dispatch: # ปุ่มรัน manual ในแท็บ Actions
  schedule:
    - cron: '0 3 * * 1' # วันจันทร์ 03:00 UTC
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [18, 20, 22] # สาม job รันขนานกัน
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm # cache ผูกกับ lockfile
      - run: npm ci
      - run: npm run lint # พังเร็วที่สุด จึงรันก่อน
      - run: npm test
      - run: npm run build
  docker:
    needs: build # push เฉพาะจากโค้ดที่เขียว
    runs-on: ubuntu-latest
    permissions:
      packages: write # สิทธิ์เขียนเดียวที่ให้
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

กรณีใช้งานจริง

เริ่ม repository ใหม่ตั้งแต่ต้น

ชั่วโมงแรกของโปรเจกต์ใหม่ไม่ควรหมดไปกับการประกอบ pipeline จากความจำ generate workflow ก่อน pull request แรกจะเกิด แล้ว CI จะบังคับมาตรฐานของคุณตั้งแต่ commit แรก

ทำ pipeline ให้เป็นมาตรฐานเดียวกันทุก service

ห้า microservice มักแปลว่า workflow เล็ก ๆ ต่างกันห้าแบบ generate รูปร่างมาตรฐานหนึ่งชุด — trigger เดียวกัน, matrix เดียวกัน, ลำดับ job เดียวกัน — แล้ว engineer ที่ย้ายไปมาระหว่าง repository จะรู้จัก pipeline อยู่แล้ว

ห่อแอป Node.js เป็น container แล้ว push ขึ้น ghcr.io

เมื่อแอป Node ย้ายเข้า container เรื่อง deploy ก็กลายเป็นเรื่อง image job Docker จะพา login, build และ push ไป ghcr.io มาให้พร้อม GITHUB_TOKEN ระดับ workflow และ permission ที่ถูกต้อง ไม่ต้องไล่จัดการ secret

เพิ่มงานตามรอบเวลาด้วย cron

บางงานไม่ควรรอ commit: nightly suite, audit dependency รายสัปดาห์ หรือ export เป็นรอบ เปิด schedule trigger ตั้ง cron expression แล้ว workflow จะมีมิติเวลาโดยไม่แตะ pipeline ที่ trigger ด้วย push

แนวปฏิบัติที่ดี

• Pin เวอร์ชัน action — ใช้ tag major version อย่าง @v4 เป็นอย่างต่ำ และใช้ commit SHA เต็มสำหรับ step วิกฤต tag ลอย ๆ คือความเสี่ยงด้าน supply chain
• ใส่ cache ก่อนอย่างอื่น — เป็น speedup ที่ถูกที่สุดก่อนจะไป optimize จุดไหนเพิ่ม
• ให้ job เล็กและเรียงลำดับ — step ที่พังเร็วไว้หน้า งานขนานที่แพงอยู่กลาง และงานเผยแพร่ไว้ท้ายสุด กันด้วย needs: ทุกจุด
• ปกป้อง main branch — ให้ workflow ต้องผ่านก่อน merge และกำหนด push ให้เฉพาะ main เพื่อให้ branch สะท้อนโค้ดที่เขียวเสมอ
• ให้ permission แบบแคบที่สุด — คง packages: write ไว้ที่ job Docker เท่านั้น และประกาศน้อยที่สุดที่อื่น
• ถือ YAML เป็นโค้ด — review การแก้ workflow ใน pull request เหมือนโค้ดทั่วไป เพราะ pipeline เป็นส่วนหนึ่งของสินค้าคุณ

สร้าง workflow YAML ของคุณวันนี้

ระยะห่างระหว่าง "ไม่มี CI" กับ "pipeline ที่แข็งแรง" มักเหลือแค่ไฟล์ที่มีรูปร่างที่ถูกต้องหนึ่งไฟล์ เปิด GitHub Actions Workflow Generator สลับ trigger และ option ของคุณ แล้ว copy workflow YAML ที่พร้อม commit ทันที ไม่ต้องมี account ไม่ต้อง upload ไม่มีอะไรต้องติดตั้ง

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• ESLint Config Generator — สร้าง lint config ที่ step lint ใน CI ของคุณจะรัน
• TSConfig Generator — ล็อก compiler option ที่ step build ของคุณพึ่งพา
• YAML Formatter — จัด workflow YAML ให้เรียบร้อยก่อน commit

ขอให้ build เขียวทุกรอบ

คำถามที่พบบ่อย

ถ: workflow ที่ generate ได้ใช้กับ npm, pnpm และ yarn ได้หมดหรือไม่?

ตอบ: ได้ คำสั่ง install และ cache step จะปรับตาม package manager ของคุณ และ cache key มาจาก lockfile ที่ตรงกัน จึงถูกต้องไม่ว่า repo จะใช้ตัวไหน

ถ: ต้องใช้ personal access token เพื่อ push image ขึ้น ghcr.io หรือเปล่า?

ตอบ: ไม่ต้อง job Docker ยืนยันตัวด้วย GITHUB_TOKEN ระดับ workflow ซึ่งใช้ได้เมื่อ job ประกาศ permission packages: write เก็บ personal access token ไว้สำหรับ registry ภายนอก

ถ: ถ้าเปิดทั้ง push และ pull_request workflow จะรันทุกครั้งที่ push หรือไม่?

ตอบ: อาจเป็นเช่นนั้นซึ่งโดยทั่วไปเป็นการเปลืองเปล่า ให้กำหนด trigger push เฉพาะ main branch เพื่อให้ pull request เป็นผู้ตรวจราย diff และ main ได้รันมาตรฐานหนึ่งรอบต่อการ merge

ถ: เริ่มจาก Node เวอร์ชันเดียวแล้วค่อยเพิ่ม matrix ทีหลังได้ไหม?

ตอบ: ได้สบาย generate ด้วยหนึ่งเวอร์ชันเพื่อให้ pipeline ช่วงแรกเร็ว แล้วค่อยขยาย list ใน matrix เมื่อผู้ใช้เริ่มพึ่งพาเวอร์ชันอื่น โครงสร้างไฟล์ยังเหมือนเดิม