retry 与 timeout 是干什么的
对特定失败原因自动重试，并给作业设置超时上限：重试用于基础设施抖动——runner 系统故障、卡死超时这类；超时防止挂起作业长期占用资源与并发额度。原则是脚本失败不重试、基础设施失败可重试。重试范围越窄越好，把脚本失败也纳入重试只会掩盖真实缺陷，让不稳定代码进入主干。
基本信息
| retry | max（次数）与 when（失败类型） |
|---|---|
| 类型 | runner_system_failure、stuck_or_timeout_failure 等 |
| timeout | 作业级超时（如 30m） |
| 原则 | 脚本失败不重试，基础设施失败可重试 |
| 交互 | 重试的作业重新走超时计时 |
典型使用场景
- 基础设施抖动：runner 节点故障时自动补跑
- 卡死清理：超时上限保证挂起作业自动结束
- 长任务保护：编译与集成测试按实际时长设置上限
- 避免掩盖缺陷：脚本失败保持不重试
- 并发治理：超时释放被占用的并发额度
- 分级差异：不同作业按风险设置不同上限
只重试基础设施失败
只重试基础设施失败
test:
script: [make test]
timeout: 30m # 超时上限：挂起作业自动结束
retry:
max: 2 # 最多重试 2 次
when: [runner_system_failure, stuck_or_timeout_failure]
# 不列 script_failure：脚本失败重试会掩盖缺陷参数读法
| 参数 | 含义 | 注意 |
|---|---|---|
| max | 重试次数上限 | 次数过多掩盖问题 |
| when | 触发重试的失败类型 | 范围越窄越好 |
| timeout | 作业最长时长 | 按实际时长留余量 |
| 卡死超时类 | stuck_or_timeout_failure | 常见基础设施类失败 |
| 执行器故障 | runner_system_failure | 典型可重试类型 |
重试范围越窄越好：把脚本失败也纳入重试会掩盖真实缺陷。
超时按实际时长校准：太紧频繁误杀，太松失去保护意义。
重试是补救不是策略：频繁命中说明执行器或网络需要治理。
组合与默认值
- 超时与重试组合：重试后重新计时，累计时长要能接受
- 默认值核对：未写超时的作业走项目级默认，先核对全局值再覆盖
超时终止会标记为超时类失败，可用重试类型匹配自动补跑一次。