📚 课程目录第4章 GitLab CI/CD入门

GitLab CI/CD 入门：.gitlab-ci.yml结构、Runner配置、stages与jobs定义、通过rules控制回归触发

这一章咱们来啃 GitLab CI/CD 这块硬骨头。说实话，我第一次接触 .gitlab-ci.yml 的时候，也被那些缩进和关键词搞晕过。后来摸透了，发现其实就几个核心东西：配置文件怎么写、Runner 怎么装、任务怎么组织、什么时候触发。下面我一个个拆开讲。

.gitlab-ci.yml 文件结构

这文件是 GitLab CI 的命根子。它放在项目根目录，GitLab 一检测到就自动解析。结构其实很简单，我习惯按这个模板来：

stages:
  - build
  - test
  - deploy

variables:
  APP_ENV: "staging"

before_script:
  - echo "开始 CI 流程"

job_build:
  stage: build
  script:
    - make build

job_test:
  stage: test
  script:
    - make test

job_deploy:
  stage: deploy
  script:
    - make deploy

几个要点：

stages：定义流水线的阶段顺序，每个阶段可以并行跑多个 job。
variables：全局变量，job 里可以覆盖。
before_script / after_script：每个 job 执行前后运行的脚本。
job：每个 job 有一个名字（如 job_build），必须指定 stage 和 script。

我个人习惯把 variables 放在文件顶部，这样其他 job 引用变量时一目了然。曾经有个项目，变量分散在多个 job 里，排查问题花了我一下午——从那以后我就统一放上面了。

Runner 配置：谁帮你跑任务？

Runner 是 GitLab CI 的执行器。你可以理解为“干活的小工”。GitLab 官方提供共享 Runner，但咱们搞回归测试，最好自己搭专用 Runner，环境可控、快很多。

配置 Runner 分几步：

在服务器上安装 GitLab Runner 二进制文件（apt / yum / Docker 都行）。
运行 gitlab-runner register，输入 GitLab 实例 URL 和注册。
选择执行器（我一般用 Docker，隔离性好）。
打标签（tags），比如 regression、linux。

注册完成后的 config.toml 长这样：

[[runners]]
  name = "my-regression-runner"
  url = "https://gitlab.example.com/"
   = "xxxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    image = "ubuntu:22.04"
    privileged = false

注意：Runner 注册后，你需要在 .gitlab-ci.yml 的 job 里加上 tags: ["regression"]，否则 Runner 不会认领这个任务。我曾经吃了这个亏，CI 卡在 pending 状态半小时，最后发现是 tag 没写对。

stages 与 jobs 定义：怎么组织回归用例？

回归测试通常需要多个 job 并行跑不同的用例集。我常用的结构是这样：

stages:
  - build
  - regression

build_app:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
  tags:
    - docker

regression_smoke:
  stage: regression
  script:
    - python run_smoke.py
  tags:
    - regression

regression_full:
  stage: regression
  script:
    - python run_full_regression.py
  tags:
    - regression

这里 regression_smoke 和 regression_full 属于同一个 stage，它们会并行执行。你想想看，如果你有 1000 条用例，全串行跑得等到猴年马月？用多个 job 并行，效率直接翻倍。

stages 与 jobs 的关系
概念	说明	举例
stages	流水线的阶段，按顺序执行	build → test → deploy
jobs	每个阶段下的具体任务	build_app, regression_smoke
同一 stage 的 jobs	并行执行，互不依赖	两路回归 job 同时跑
不同 stage 的 jobs	按顺序执行，前 stage 全部成功后下一 stage 才开始	build 完成 → regression 启动

关键点：回归测试建议放在 build 之后单独 stage。这样如果 build 失败，回归根本不会触发，省得浪费资源。我见过有人把回归和 build 放在同一个 stage，结果 build 报错了回归还在跑……简直浪费感情。

通过 rules 控制回归触发

这才是回归自动化的精髓。你想啊，不是每次代码提交都得跑全量回归的——如果只是改了个 README，跑 2 小时回归就太蠢了。GitLab 提供了 rules 字段，可以按条件决定 job 要不要跑。

我常用的几个场景：

只针对指定分支触发回归：比如 main 和 release/*。
根据改动文件触发：只有修改了 src/ 或 tests/ 目录才跑。
通过变量控制开关：比如手动触发 pipeline 时传一个 RUN_REGRESSION=true。

看个实际例子：

regression_full:
  stage: regression
  script: python run_full_regression.py
  rules:
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main"'
      changes:
        - "src/**/*"
        - "tests/**/*"
      when: always
    - if: '$TRIGGER_REGRESSION == "true"'
      when: always
    - when: never

这个规则的意思是：

如果是 push 事件，且分支是 main，且改动了 src 或 tests 目录下的文件，就跑。
或者，如果手动触发时传了 TRIGGER_REGRESSION=true，也跑。
其他情况，不跑（when: never）。

注意规则从上到下匹配，一旦命中就停止。我把 when: never 放在最后当兜底。以前我写反了顺序，结果所有提交都触发了回归……团队同事差点把我扔出窗户。

还有一个小技巧：用 rules:changes 检测文件变化时，路径模式支持通配符。我习惯写成 "src/**/*" 而不是 "src/*"，因为前者能匹配子目录。

整张流程图：看看全貌

下面这张 SVG 把咱们讲的内容串起来了。从代码提交到 Runner 执行，再到 rules 判断是否触发回归，一目了然。

核心思路：别让回归变成“无脑全量跑”。用 rules 做“精准打击”，该省则省。

这一章的内容就这些。记住：.gitlab-ci.yml 的编排、Runner 的标签匹配、stages 的顺序管理、rules 的条件控制——这四个东西组合起来，就能让回归测试自动化得又稳又聪明。