Jobs 与运行器

这一课你将能做到

1. 配置多个 job，理解默认并行与用 needs 串行的差别，并让部署 job 挂在测试 job 之后
2. 解释 runner 是「一次性虚拟机」：为什么每个 job 都要重新 checkout、装工具
3. 写一个入门级 strategy.matrix，用同一套步骤测两个 Node（或 Java）版本

为什么要学

一个 workflow 里往往不止一件事：本站要测 backend 与 platform。若塞进同一个 job 的一长串 step，一边失败难看清边界，也无法并行省时间。

Job 是「一台 runner 上的一组 steps」；多 job 默认各开一台机器一起跑。需要「先构建再部署」时，用 needs 排依赖。搞不清并行/串行时，人要么白白串行浪费时间，要么在没产物的情况下就去部署。

理解 runner 原理还有一层面试价值：「你们的 CI 跑在什么机器上？为什么每次都要重新装依赖？」这类问题考的就是对临时虚拟机生命周期的理解。

先建立图像

workflow 被触发
        │
        ├─ job: backend    ── runs-on ubuntu ── steps…
        │                     （独立机器 A）
        │
        └─ job: platform   ── runs-on ubuntu ── steps…
                              （独立机器 B，默认同刻开跑）

若 platform 写了 needs: [backend]
则：backend 成功 → 才启动 platform；backend 失败 → platform 直接 skip

人话：每个 job 像一条独立厨房线。默认两条线同时炒菜；写了 needs 就是「头菜出锅后才能做主菜」。

概念	人话
runner	执行 job 的虚拟机（托管或自建）
runs-on	选哪类机器镜像
needs	本 job 依赖哪些 job 成功
matrix	同一 job 模板 × 多组变量 = 多次运行
timeout-minutes	防卡死的保险丝

跟着做

步骤 1：写两个并行 job

在 .github/workflows/ci.yml 中：

name: CI

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  backend:
    runs-on: ubuntu-latest
    steps:
      - name: 假装测 Java
        run: echo "backend ok"

  platform:
    runs-on: ubuntu-latest
    steps:
      - name: 假装测 Node
        run: echo "platform ok"

手动跑一次：Actions 图上应看到 两个 job 几乎同时开始（或短间隔内都变绿）。

步骤 2：加上 needs 看串行

改 platform：

  platform:
    runs-on: ubuntu-latest
    needs: backend   # backend 成功后才跑
    steps:
      - run: echo "platform after backend"