持续集成CI

CI 把每次提交变成一条自动流水线

持续集成（CI）在你 push 或发 PR 时自动跑一串 stage——装依赖、Lint、测试、构建。任一 stage 失败就熔断（红灯、阻止合并），全绿才放行。下面选一种提交类型，点「触发流水线」逐步推进，看健康的提交怎么全绿、带回归的提交怎么在测试 stage 红灯熔断。

知识点总结

把流水线模拟器里能直接看到的东西命名下来。

• stage 编排：装依赖 → Lint → 测试 → 构建是按顺序跑的独立步骤，每步有退出码和日志。
• push / PR 触发：CI 不是常驻服务，而是仓库收到 push 或 PR 时才启动；「触发流水线」就是在模拟这次 push。
• 全绿才放行：所有必要 stage 退出 0，PR 才允许合并——把「合并前才手工测」变成「每次提交都自动验证」。
• 失败即熔断：一个 stage 退出非 0，后续 stage 直接跳过（不浪费构建算力），PR 红灯阻止合并。
• 反馈循环：失败的 stage 展开 stderr（断言、行号），照着修代码后重跑，转绿再合并。

什么时候靠 CI 把关

从「不靠 CI 会发生什么」判断。

不适用：纯个人草稿、还没有测试和构建命令的项目——先有可跑的检查，CI 才有意义；否则只是空跑流水线。

怎么用

从「PR 推上去到看到结果」的最短路径。

1. 写好可跑的检查：npm ci、npm run lint、npm test、npm run build 本地能跑通，是 CI 的输入。
2. 在仓库配置 workflow：GitHub Actions / GitLab CI 写一个 yaml，声明 stage、触发条件（push / PR）和所需环境。
3. 把必要检查设为 required：在分支保护里勾选，使 CI 失败时 PR 真的不能合并。
4. 读 PR 上的状态：看哪个 stage 绿 / 红，红灯点开看日志和行号。
5. 修代码后重跑：照 stderr 改完推送，CI 自动重跑，转绿后再合并。

正反例：CI 是不是真的门禁

目标都是「不让坏代码进主分支」，只改一个关键选择——CI 失败到底挡不挡得住合并。