提升流水线稳定性需聚焦可恢复的外部交互环节（如docker push）并实施智能重试：仅对connection refused、502/503/504、429等瞬时错误重试，避开401/403/缓存计算失败等不可重试错误，并采用指数退避策略避免重试风暴。
构建流水线稳定性不只靠“一次成功”，更依赖对常见失败的智能应对。Docker镜像构建本身（docker build）默认不带重试，但构建过程中的关键依赖环节——尤其是后续的 docker push ——极易因网络抖动、仓库限流或临时认证失效而中断。真正提升稳定性的重试机制，应聚焦在这些可恢复的外部交互环节，而非盲目重试构建本身。
只对可重试错误启用重试
不是所有失败都适合重试。重试前必须区分错误类型：
-
可重试错误：如
connection refused、i/o timeout、502/503/504、429 Too Many Requests—— 这些多由瞬时网络或服务端负载引起，等待后大概率恢复 -
不可重试错误：如
401 Unauthorized、403 Forbidden、denied: requested access denied、failed to compute cache key—— 表明凭证过期、权限不足或Dockerfile语法/上下文错误，重试无效，需人工介入
建议在脚本中用 docker push 的退出码 + 错误输出关键词做简单判断，跳过非重试类错误。
采用指数退避策略控制重试节奏
固定间隔（如每次等3秒）在高并发场景下易引发“重试风暴”，加重Registry压力。指数退避能自然错峰：
- 第1次失败后等1秒，第2次等2秒，第3次等4秒，第4次等8秒……
- Shell中可用
SLEEP=$((2 ** i))实现；Go或Python脚本中推荐用time.Sleep(time.Second * time.Duration(1 - 生产环境建议最大重试3–5次，总耗时控制在2分钟内，避免阻塞流水线
结合超时与上下文取消机制
单靠重试无法解决长卡死问题。应在重试外层加总时限保护：
- 用
timeout 300 ./push-with-retry.sh限制整个重试流程不超过5分钟 - 在CI/CD平台（如GitHub Actions）中，为推送步骤单独设置
timeout-minutes: 6，防止无限挂起 - 若使用自研工具或SDK调用Registry API，务必配置
http.Client.Timeout（建议30–60秒），避免单次请求拖垮整体
优先使用平台原生重试能力
比手写脚本更可靠的是利用CI/CD平台内置机制，它们已集成错误识别、日志追踪和可视化重试记录：
-
GitHub Actions：在 step 级别配置
strategy: { max-requests: 3 }或使用retry: { max-attempts: 3 } -
GitLab CI：直接写
retry: 2（最多再试2次，共3次） -
Jenkins Pipeline：用
retry(3) { sh 'docker push ...' }，配合timeout(time: 5, unit: 'MINUTES')
这些方式无需维护额外逻辑，失败原因和重试次数在UI中一目了然，利于快速归因。
