fix(ci): release workflow is idempotent against an already-existing release - #105
Merged
open-coder-ai merged 1 commit intoSep 2, 2026
Merged
Conversation
…elease v0.8.0 exposed a real bug: the owner creates the GitHub Release via the UI (which creates the tag and the published release together), and that tag push is what triggers this workflow -- so `gh release create` always finds the release object already there and fails. PyPI publish had already succeeded by then, so the release went out with the right notes but zero attached binaries/checksums, silently, every time. Try `gh release upload ... --clobber` against the release that (almost always) already exists first; fall back to `gh release create` only if none does, so a tag pushed without a pre-existing release still gets one. Doesn't touch the owner's release title/notes when the release already exists. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Claude <noreply@anthropic.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The v0.8.0 release exposed a real, recurring bug in
.github/workflows/release.yml'sreleasejob. Its practice is to create the GitHub Release via the UI first (which creates the tag and the published release together) — that tag push is what triggers this workflow. By the time thereleasejob runs,gh release createalways finds the release object already there and fails:gh release create "$GITHUB_REF_NAME" ...errors on an existing release.PyPI publish (the
pypijob) is independent and had already succeeded — v0.8.0 is correctly on PyPI. But the failedreleasejob step meant the platform binaries and their checksums were never attached to the release, silently, every time this has run this way.The fix
Try
gh release upload "$GITHUB_REF_NAME" dist/chock* dist/checksums.txt --clobberagainst the release that (almost always) already exists; fall back to the originalgh release createonly when none does, so a tag pushed without a pre-existing release (e.g. directly viagit push --tags) still gets one. Doesn't touch the release's title or notes when it already exists — only attaches assets.Verification
python3 -c "import yaml; yaml.safe_load(...)"— YAML parses clean.bash -n— syntax clean. (zizmor/actionlintneed authenticated GitHub API access this local check didn't have; CI runs both.)releasejob, "Create GitHub Release" step —gh release createfailing exactly as diagnosed.Note
v0.8.0's release (https://github.com/open-coder-ai/chock/releases/tag/v0.8.0) currently has zero attached assets as a result of this bug. This PR prevents it recurring on the next tag; it doesn't retroactively attach v0.8.0's binaries (this session has no
gh release uploadaccess outside this workflow). If the platform binaries matter for v0.8.0 specifically, they can be downloaded from that same failed run's artifacts and uploaded by hand.🤖 Generated with Claude Code
https://claude.ai/code/session_01RcphZmVVXoy8Jf2tUtcsC3
Generated by Claude Code