Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

release.sh derives a tag name that GitHub permanently refuses

Đang mở
  • Có gì không ổn?
#116 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
git, github, go, shell
Lĩnh vực
devops, release

Hướng nghiên cứu

Bắt đầu trong scripts/release.sh, theo dõi việc phát hiện tag, đánh số dự phòng và luồng push tag. Đọc release_workflow_test.go và require_newest_release_test.go, đồng thời xác nhận workflow xử lý các tag v*.. như thế nào. Hoàn thành khi một tag được dành riêng không làm dừng việc đánh số release và release tiếp theo tuân theo luồng commit và tag thông thường của script.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
3
Fork
0
Merge trung bình
3 giờ 10 phút
Pull request đã merge (30 ngày)
39

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của labstack/onebox

Tất cả issue của labstack/onebox

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.