GitHub Actions Anatomy：Workflow、Job、Runner、Step 到底誰在執行

Learning outcomes

• 能區分 workflow、job、runner、step、action。
• 能解釋 checkout/setup runtime 的必要性。
• 能判斷 env/secret 的 scope。
• 能由第一個 failure step 找 root cause。

1. Execution hierarchy

workflow
└─ job
   ├─ runner
   ├─ checkout
   ├─ setup runtime
   ├─ install
   ├─ check
   ├─ build
   └─ verify

2. Runner 是新的執行環境

- checkout repository
- setup Node 24
- npm install
- npm run check
- npm run build

你的 laptop 有 node_modules、global CLI、登入 session，不代表 runner 也有。CI 的價值之一就是逼依賴與環境被明確描述。

3. Job 之間不天然共享 filesystem

job A → build artifact
          ↓ upload
job B ← download artifact
       → deploy

如果不同 jobs 要共用輸出，需明確 artifact/cache mechanism。

4. Secrets 與 scope

step needs:
  CLOUDFLARE_API_TOKEN

other steps:
  no deploy secret

Secrets 應最小化注入範圍，也不應被 echo 到 log。能在 workflow 引用 secret 不代表值存在 repo source。

5. Manual production gate

CI 可以自動跑，production deploy 則使用 manual dispatch / confirmation。這將「品質驗證」和「改變 production」拆成不同風險層。

Project checkpoint：Course Workspace v11

push / pull request
  ↓
CI:
  syntax
  curriculum checks
  tests
  build
  artifact verify

manual approval
  ↓
production deploy
  ↓
smoke

Debug evidence：Workflow 紅了

先找哪個 job、哪個 step 第一個 non-zero。若 install 已失敗，後面的 build 根本沒執行；不要分析不存在的 build failure。