gitlab ci长耗时测试应合理拆分、主动延时、分阶段反馈：①job级设timeout（如7200秒）；②并行分片执行；③输出进度日志与中间产物；④分离至独立pipeline并资源隔离。
GitLab CI 默认单个 Job 超时时间为 1 小时（60 分钟），而长耗时测试（如端到端测试、性能压测、大型集成测试）很容易触发超时中断，导致流水线失败或结果丢失。关键不是“避免耗时”，而是**合理拆分、主动延时、分阶段反馈**。
设置合理的 Job 超时时间
对已知耗时的测试任务，显式延长超时阈值，避免被强制终止：
- 在 job 级别用 timeout 字段覆盖全局默认值，单位为秒（例如
timeout: 7200表示 2 小时） - 不建议全局修改 timeout（影响所有 job），应按需精准设置
- 注意 Runner 配置中也有
limit或executor_timeout，需同步确认其是否更高，否则仍会截断
拆分测试套件并行执行
把一个大测试集切分成多个子集，并发运行，总耗时大幅下降：
- 按模块划分：如
tests/api/、tests/ui/、tests/db/各自独立 job - 用工具自动分片：Pytest +
pytest-xdist（--numprocesses=4）、JUnit +maven-surefire-plugin的forkCount - GitLab 原生支持
parallel: N，自动复制 job 并分配不同环境变量（如TEST_PART）驱动分片逻辑
启用分阶段报告与中间状态反馈
长测试不能只等最后结果；需让开发者及时感知进展和早期失败：
- 在脚本中定期输出进度日志（如每 5 分钟打印当前通过率），GitLab UI 实时可见
- 使用
artifacts:untracked: true持久化中间产物（如部分测试截图、日志片段） - 结合
coverage正则提取阶段性覆盖率，或用script中调用 API 主动推送状态到看板/IM
分离长耗时测试到独立 Pipeline
不把耗时测试和快速单元测试混在同一 pipeline，避免阻塞主反馈流：
- 用
rules或only/except控制触发条件：例如仅main分支或schedule定时任务才运行全量 E2E - 配置单独的
stages: [e2e]和专用 Runner 标签（如tags: [e2e-runner]），资源隔离 - 允许该 job
allow_failure: true，失败不影响合并，但保留记录供人工跟进
