Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

release.sh derives a tag name that GitHub permanently refuses

未关闭
#116 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
git, github, go, shell
领域
devops, release

调研方向

从 scripts/release.sh 开始,跟踪 tag 的发现、回退编号以及 tag push 路径。阅读 release_workflow_test.go 和 require_newest_release_test.go,并确认 workflow 如何处理 v*.. tag。完成标准是:保留的 tag 不会中止 release 编号,且下一个 release 遵循脚本正常的 commit 和 tag 流程。

由索引模型根据 Issue 内容生成。

描述

bug

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

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

labstack/onebox 的其他 Issue

查看 labstack/onebox 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。