GitLab Topic
GitLab CI/CD 与 Runners 入门
建立更扎实的 GitLab CI/CD、pipeline、job、runner 心智模型，并理解它们怎样参与 Merge Request 准入。
- 已经会基础 Git、准备系统学习 GitLab 协作的人
- 要在团队里使用 Merge Request、Issue Board 和 CI/CD 的开发者
- 知道 branch、commit、push、remote 的基本作用
- 愿意把平台功能和 Git 操作一起理解
- 只记 GitLab 页面操作却忽略底层 Git 边界
- 把平台策略误当成可以替代本地历史判断
为什么 GitLab 学习离不开 CI/CD
GitLab 和很多平台最大的差异之一，就是它把协作和自动化绑得非常紧。
如果你理解 Merge Request，却不理解 pipeline 和 runner，那么平台的很多行为仍然会显得很抽象。
先建立最小模型
先把这几个词彻底分开：
pipeline：一次完整流水线运行job：流水线中的单个任务runner：执行这些任务的运行环境.gitlab-ci.yml：声明规则和任务的配置入口
学习顺序不应该是先背语法，而应该是先搞清角色分工。
在很多 GitLab 团队里，pipeline 不是合并后的附加动作，而是决定 Merge Request 能不能通过的核心证据层。
为什么 MR 和 pipeline 要一起理解
在 GitLab 中，MR 常常会同时承接这些信息：
- 测试是否通过
- lint 是否通过
- build 是否成功
- 策略检查是否满足
所以 pipeline 在这里不是单独系统，而是协作闭环的一部分。
一个最小配置长什么样
stages:
- test
test:
stage: test
script:
- npm ci
- npm test
这个最小示例已经足够说明三件事：
- 任务在哪里声明
- 任务怎么组织进 stage
- 执行结果怎样反馈回 Merge Request
Runner 为什么必须单独理解
很多新手只盯 .gitlab-ci.yml，但真正执行 job 的是 runner。
没有 runner，配置写得再完整也不会真正产生价值。
runner 直接影响：
- 任务运行环境
- 执行权限边界
- 可用性与速度
- 敏感 job 是否能在受信环境里运行
所以“pipeline 失败”并不总是 YAML 有问题，也可能是 runner、权限或环境问题。
更稳的落地顺序
如果团队刚开始建立 GitLab CI/CD，更推荐：
- 先让一个最小 pipeline 稳定可跑
- 再确认 runner 由谁负责、在哪里执行
- 把 pipeline 状态和 MR 准入标准挂钩
- 最后再逐步扩到环境、部署和高级规则
这样能避免一开始就陷入“配置很复杂，但团队没人真正信任 CI”的状态。
图例理解
MR 事件.gitlab-ci.ymlRunner 可用性
Job 状态Merge 信号运维反馈
当团队说“CI 又坏了”时，问题可能在配置、runner、权限，甚至 MR 准入定义本身。
一个简单但可靠的流水线，比一个华丽但经常不稳定的流水线更能建立团队信任。
runner 不是中立流水管道，它决定 job 在哪里执行、用什么权限执行、是否触碰敏感环境。因此它本身就是协作和安全模型的一部分。
跟着做一遍
目标是搞清楚 MR 上看到的 pipeline 状态，到底是如何被执行出来的。
找一个带最小 .gitlab-ci.yml 的小项目。 从功能分支打开一个 Merge Request。动手试
- 先在 MR 页面里看它关联了哪条 pipeline。
- 再进入 pipeline 看具体有哪些 jobs。
- 确认这些 jobs 是由哪个 runner 执行的。
- 最后问自己：如果 runner 不可用或权限受限，这个 MR 会发生什么变化？
- 你会把 MR 状态和实际执行基础设施联系起来。
- 会意识到 CI 问题不总是 YAML 问题。
- 以后排查 GitLab pipeline 时会更快找到真正的故障层。
- 如果 pipeline 根本没启动，先查 runner 和触发规则。
- 如果某些敏感 job 没出现，先看权限或保护策略。
- 如果团队只会改 YAML 却说不清 runner 状态，说明模型还没真正建立起来。