ci(mirror): 每资源计时 + 2m 上传上限(超时 warn 并跳过)

[Sunrisepeak]

动机

v0.0.94 发布时 publish-ecosystem 被 30min job timeout 杀掉,日志里看不出是哪个资产在慢。事后查:gtc 跨境传 linux-x86_64(8.4MB)与 linux-aarch64(30.5MB)两个大件卡住,GitHub 端 8 个全好、GitCode 端只差这两个,最后靠本地 gtc release upload 手工补齐(已核验两端 16 个资产全 200 + 字节一致)。

改动

1. 先查再传(原有行为,补上 host 标签):probe 到已 serving → already mirrored, skipping,绝不重传。
2. 每资源计时:上传返回即打印 <github|gitcode> <资产> (<大小>) uploaded in Ns。
3. 2m 上限(MIRROR_UPLOAD_TIMEOUT,默认 120s):超时 → WARN ... exceeded the 120s cap after Ns — skipping,放弃该资产、后续轮次不再重试。
4. 每条 mirror leg 结束打印耗时;gate 失败时 hint 出手工补传命令。

为何这个 cap 与 v0.0.90 事故不同(重要)

脚本里原有一条血泪注释:v0.0.90 用 timeout 300 包上传,杀掉慢但在推进的 PUT 然后重传,每次从字节零重来,永不收敛,把 20min job 预算拖垮。

本 cap 的安全性来自 超时即放弃、绝不重试。完整性 gate 仍是唯一 pass/fail —— 漏传会响亮报错,而不是静默发半个镜像。顶部注释已按此改写。

⚠️ 已知取舍(需要 review 拍板)

120s 对 GitHub runner → GitCode 跨境传 30.5MB 的 aarch64 包大概率不够。真这样的话每次发版该资产都会被 warn+skip → gate 红 → 仍需人工补传(即这次的实际流程)。

差别是:从「30 分钟静默挂死」变成「2 分钟内明确报出是哪个资产、多大、跳过了」 —— 可观测性是净赚。若希望 CI 全自动闭环,可 (a) 调大 MIRROR_UPLOAD_TIMEOUT,或 (b) 按资产大小分档给 cap。当前实现已把它做成 env 变量,改一行即可。

验证

• 真实 0.0.94 镜像干跑:16 资产两端全 200、已存在全部 skip、206s 通过。
• stub 双分支(用 PATH 上的真可执行文件,而非 shell function —— timeout 对函数无效,第一版测试正是栽在这):
  • 快传 → [mirror] github big.tar.gz (2.9MB) uploaded in 1s
  • 慢传 → [mirror] WARN: gitcode big.tar.gz (2.9MB) exceeded the 2s cap after 2s — skipping (not retried; the verify gate below decides the release)