GitLab CI 核心概念与后台任务测试场景

1.1 Pipeline、Job 与 Stage 的定义与关系

GitLab CI 的自动化流水线由三个基本层级构成：Pipeline、Stage 和 Job。理解这三者的层次关系是配置一切 CI 流程的基础。

• Pipeline（流水线）：一次完整 CI/CD 流程的实例。当代码推送、合并请求创建或定时触发时，GitLab 会创建一个新的 Pipeline。Pipeline 包含若干 Stage，且每个 Pipeline 都有唯一的 ID 和状态（pending/running/passed/failed）。
• Stage（阶段）：Pipeline 内的逻辑分组，同一 Stage 内的 Job 默认并行执行（除非使用 needs 或 parallel 调整）。常见的 Stage 包括 build、test、deploy。
• Job（任务）：执行实际操作的单元，例如编译、运行测试、部署。每个 Job 运行在独立的 Runner 环境中。

1.2 后台任务在 CI 中的典型场景

后台任务指那些不立即返回结果、需要持续监听、异步调用或延迟检测的 Job。常见场景包括：

场景	描述	典型配置要点
长时间集成测试	性能测试、压力测试或端到端测试，运行时长超过 30 分钟	使用 timeout 调整 Job 超时，配合 artifacts:expire_in 保存日志
异步任务轮询	触发外部系统后定期检查任务状态（如云部署、数据迁移）	使用 rules 与 allow_failure 处理间歇性失败，结合 API 轮询脚本
定时后台批处理	每日构建、报告生成等不需要立即反馈的任务	通过 schedule 或 rules:if 按日期触发
守护进程健康检查	启动一个后台服务后持续检查其 HTTP 端口或日志输出	Job 内使用 background: true 启动服务，主 Job 通过 API 或文件系统检测

1.3 最小 Pipeline 示例（YAML 配置）

以下配置展示了一个包含三个 Stage 的 Pipeline，其中 long_test 作为后台任务，使用 timeout 和 retry 处理超时与重试。

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building application..."
    - make build

long_integration_test:
  stage: test
  script:
    - echo "Starting background integration test..."
    - timeout 600s ./run_long_test.sh
  timeout: 15m
  retry: 2
  artifacts:
    paths:
      - test_logs/
    expire_in: 7 days

deploy_job:
  stage: deploy
  script:
    - echo "Deploying..."
  only:
    - main

1.4 Pipeline 层次结构图

下方 SVG 图展示了 Pipeline → Stage → Job 的树形关系，并高亮了后台任务 Job 与普通 Job 的区分。

1.5 常见概念混淆与避坑

• Stage 不能动态创建：所有 Stage 必须在 stages 中事先声明。后台任务不能临时插入 Stage，只能通过 rules 控制是否执行。
• Job 超时与 Pipeline 超时：Job 级别 timeout 覆盖 Pipeline 级别的默认超时。后台任务若需要长时间运行，要同时设置两层超时，避免 Pipeline 被强制终止。
• Runner 资源竞争：后台任务可能耗尽 Runner 的并发槽位，导致其他 Job 排队。建议为后台任务使用单独的 Runner tag 或设置 resource_group 限制并发。