gitlab runner需先安装、注册并在线才能执行job，否则任务将卡在pending状态；注册时须配置url、token、executor及tags，且yaml中job必须显式声明匹配的tags。
GitLab CI 中 Runner 不是自动就绪的“开关”，它得先装、注册、在线，才能跑测试。配置的核心不是写 YAML，而是让 Runner 能被正确匹配并执行 job —— 否则测试 job 会一直卡在 pending 状态，连日志都看不到。
Runner 必须安装并注册到项目
Runner 是独立于 GitLab 的代理程序，必须手动部署在能联网的机器上（Linux 最常用）：
- Ubuntu 安装示例：
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bashsudo apt install gitlab-runner -y - 注册时需从 GitLab 项目页面获取两个关键信息：Runner URL（如
https://your-gitlab.com/）和 Registration Token（Settings → CI/CD → Runners → Expand → Registration token） - 执行注册命令，指定 executor 类型（推荐
docker）和标签：sudo gitlab-runner register \<br> --url "https://your-gitlab.com/" \<br> --registration-token "xxx" \<br> --executor docker \<br> --docker-image "alpine:latest" \<br> --description "test-runner" \<br> --tag-list "ci,test" \<br> --run-untagged false
job 必须带 tags，且与 Runner 标签匹配
Runner 注册时声明的 --tag-list（比如 "ci,test"）决定了它能接什么任务。YAML 中每个 job 必须显式声明 tags，否则不会被调度：
- 错误写法（无 tags）：job 永远 pending
- 正确写法：
test:<br> tags: [test] # 必须和 Runner 的 tag 完全一致<br> script: - pytest tests/
- 多个 Runner 可用不同 tag 区分用途，比如
test、build、e2e，便于资源隔离
测试 job 要自备运行环境，不能依赖默认镜像
Runner 只负责拉起容器、执行命令，不预装任何测试工具。常见失败原因是 pytest: command not found 或 No module named requests：
- 用语言专用镜像起步更稳，例如：
image: python:3.11-slim，而非docker:latest - 在
before_script中统一准备环境：before_script:<br> - pip install --upgrade pip<br> - pip install -r requirements.txt
- 若用虚拟环境，记得激活：
- python -m venv .venv<br> - source .venv/bin/activate<br> - pip install -r requirements.txt
让测试结果可读、可追踪
光跑通不够，要让失败可定位、报告可查看：
- pytest 加参数提升可读性：
pytest tests/ --tb=short -x（短堆栈 + 遇错即停） - 上传测试报告，GitLab 会自动解析展示：
artifacts:<br> reports:<br> junit: "test-results.xml"
（需 pytest 运行时生成，例如：pytest --junitxml=test-results.xml） - 加
allow_failure: false（默认就是）确保测试失败时整个 pipeline 中断，避免错误产物流入后续阶段
