超时控制是什么
为作业与流水线设置运行上限：挂死的构建不会无限占用资源，排队、告警与成本预算也更可靠。三家配置位置不同——GitLab 在作业/项目设置与 Runner 层都有超时，GitHub 用 jobs.<id>.timeout-minutes（默认 360 分钟），Jenkins 用 options 里的 timeout。超时值不是拍出来的：按历史时长的分位数上浮设定，触发超时时先判断是真变慢还是阈值太紧。超时触发后按查现场、定位根因、再决定是否调整的顺序处理，直接调大会掩盖问题。
基本信息
| GitLab | 作业 timeout 继承项目设置（可覆盖），Runner 也有独立超时 |
|---|---|
| GitHub | jobs.<id>.timeout-minutes（默认 360 分钟） |
| Jenkins | options { timeout(time: 30, unit: 'MINUTES') } |
| 联动配置 | 告警阈值早于作业超时，避免无效等待 |
超时值怎么定
| 依据 | 做法 |
|---|---|
| 历史时长 | 取 P99 上浮 20-50% 作为初始值 |
| 作业类型 | E2E 与构建分开设，别用同一上限 |
| 资源成本 | 超时越长挂死代价越大，定期复查 |
| 告警联动 | 告警阈值早于超时触发 |
| 环境差异 | 本地与 CI 时限分开评估 |
| 回归校验 | 调整后观察一周，防误杀或复活挂死 |
典型使用场景
- 长任务防护：E2E、集成测试设明确上限，防挂死
- 队列治理：Runner 被占满时先查有没有过大的超时配置
- 预算控制：超时影响计费与并发占比，纳入成本视角
- 排查辅助：超时触发后自动收集现场日志与栈
- 演练：故意制造挂死场景，验证超时路径与告警效果
- 继承关系梳理：项目级、作业级与 Runner 级叠加时，按最短生效值设计
GitHub
GitHub
jobs:
e2e:
timeout-minutes: 30GitLab
GitLab
e2e:
timeout: 30 minutes
script: ./ci/e2e.sh超时值按 P99 时长上浮设定；触发超时后先看是否真的变慢，而非直接调大。
超时与重试要一起算总预算：重试次数乘单次超时等于最坏耗时。稳定变慢要治根因，偶发抖动再看阈值。