release.sh derives a tag name that GitHub permanently refuses
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
调研方向
从 scripts/release.sh 开始,跟踪 tag 的发现、回退编号以及 tag push 路径。阅读 release_workflow_test.go 和 require_newest_release_test.go,并确认 workflow 如何处理 v*.. tag。完成标准是:保留的 tag 不会中止 release 编号,且下一个 release 遵循脚本正常的 commit 和 tag 流程。
由索引模型根据 Issue 内容生成。
描述
What happened
All releases and tags were deleted from this repository on 2026-08-24. scripts/release.sh derives the next tag by scanning existing v<year>.<month>.* tags and incrementing the highest match, falling back to .0 when it finds none:
release_tags=$(git tag --list "v${release_period}.*" --sort=-v:refname)
...
if [ -z "$release_last" ]; then
release_number=0
With no tags present it computes v2026.8.0, which cannot be created. GitHub's immutable releases permanently reserve a tag name once a release has been published under it, and the reservation outlives deleting both the release and the tag — recreating the ref returns 422 Reference update failed.
v2026.8.0 through v2026.8.10 are all burned for this repository. v2026.8.11 was tagged by hand to restart the series, so the script derives correctly again — but the fallback remains wrong for the next reset, and for the first release of any future month whose numbers were used before.
Suggested fix
Treat a 422 from the tag push as "this name is reserved" and retry with the next number, instead of aborting. Alternatively, when no local tags match the series, query the API for the highest tag the repository has ever published rather than assuming .0 is available.
One deviation in the v2026.8.11 tag
release.sh normally creates a chore(release): <tag> commit on top of main and pushes the commit and tag atomically. v2026.8.11 was tagged directly on the existing main commit instead, so there is no synthetic release commit for it. Nothing appeared to depend on that commit — the workflow triggers on v*.*.* tags, and neither release_workflow_test.go nor require_newest_release_test.go references it — but it is a difference from every earlier tag and worth confirming before the next release runs through the script.
- 主要语言
- Go
- 星标
- 3
- 派生
- 0
- 平均合并
- 2 小时 44 分钟
- 30 天内合并 PR
- 49
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
labstack/onebox 的其他 Issue
-
bug
难度 1/5 1 小时以内 新手友好度 80/100
-
bug
难度 1/5 1 小时以内 新手友好度 85/100
-
bug
难度 1/5 1 小时以内 新手友好度 85/100
-
bug
难度 3/5 1-2 天 新手友好度 65/100
-
难度 4/5 3-5 天 新手友好度 55/100
相似的 Issue
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 76/100
-
agentic-workflows
难度 2/5 1-3 小时 新手友好度 70/100
microsoft/agent-framework-go#1179 ·
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
-
[Bug]: OLLAMA_KEEP_ALIVE="5m" / "24h" crashes Ollama embedding and vision models with ValueError 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
infiniflow/ragflow#20223 · 1 个 reaction ·
-
bug needs triage pkg/translator/faro
难度 2/5 1-3 小时 新手友好度 88/100
open-telemetry/opentelemetry-collector-contrib#51484 · 1 条评论 ·