release: wait longer for npm to expose published client packages before failing
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 74/100
调研方向
从 .github/workflows/release.yml 中的 release job 和 release/scripts/test_release_workflow_structure.py 中的 workflow 结构检查开始。找出平台和 root 包的公开截止时间及其轮询消息。延长截止时间，每分钟报告仍未出现的包，保留完整性不匹配时立即失败的行为，然后运行指定的结构测试。
由索引模型根据 Issue 内容生成。
描述
Why
The v0.42.0 publication run failed its npm job on the first attempt. The job "Reconcile platform packages, then publish the root package" (.github/workflows/release.yml) publishes the platform packages, then polls client_registry.py npm-state for each one until the exact version is exposed, giving up after 600 seconds (platform_deadline=$((SECONDS + 600))). It failed with:
npm did not expose exact platform package registrystack-client-linux-arm64-gnu-0.42.0.tgz
All three platform packages had been published. The root package had not, because the job stops before publishing it. A few minutes later every platform version endpoint returned the exact integrity. The supported recovery (verify-recovery, then publish --plan ... --wait) reconciled the published platforms and published the root package with no change, so the release completed. That still cost a second protected-environment approval and about 15 minutes.
npm's per-version endpoint can lag past ten minutes after a successful npm publish. The deadline treats that lag as a failure, but the recovery path shows it is not one.
Change
- Raise the platform and root exposure deadlines, for example to 30 minutes, and print a progress line every minute naming the packages still absent.
- Keep the fail-closed behaviour: an exposed package whose integrity differs from the candidate still fails at once, and nothing is republished.
- Cover the change in
release/scripts/test_release_workflow_structure.py.
Acceptance
A publication whose platform packages take more than ten minutes to appear completes in one run, and the failure for an integrity mismatch is unchanged.
- 主要语言
- Rust
- 星标
- 2
- 派生
- 0
- 平均合并
- 9 小时 19 分钟
- 30 天内合并 PR
- 275
环境准备
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
registrystack/registry-stack 的其他 Issue
-
area:breg bug
难度 2/5 1-3 小时 新手友好度 74/100
registrystack/registry-stack#2307 ·
维护者通常 1 天内回复
-
area:breg area:docs documentation
难度 2/5 1-3 小时 新手友好度 82/100
registrystack/registry-stack#2302 ·
维护者通常 1 天内回复
-
area:docs documentation
难度 2/5 1-3 小时 新手友好度 76/100
registrystack/registry-stack#2253 ·
维护者通常 1 天内回复
-
area:coordinator bug
难度 2/5 1-3 小时 新手友好度 82/100
registrystack/registry-stack#2252 ·
维护者通常 1 天内回复
-
area:breg documentation
难度 1/5 1-3 小时 新手友好度 88/100
registrystack/registry-stack#2233 ·
维护者通常 1 天内回复
查看 registrystack/registry-stack 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
project-robius/robrix#1177 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
ClickHouse/clickhouse-rs#497 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
farion1231/cc-switch#8696 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100