fix(ci): make Release workflow idempotent on existing tag#244
Merged
Conversation
The "Create Release" step in release.yml runs `gh release create $VERSION ...` unconditionally. This fails with "a release with the same tag name already exists" if a maintainer ran `gh release create` manually right after pushing the tag — which is exactly what happened on every release in the v0.5.0 / v0.5.1 / v0.6.0 sequence. Net effect: the release page exists with the changelog notes but has no binary / VSIX / SHA256 assets attached. Fix: make the step idempotent. If `gh release view $VERSION` succeeds (release already exists), `gh release upload --clobber` the built assets to the existing release. Otherwise create it the normal way. `--clobber` lets a re-run overwrite assets that a previous failed attempt partially uploaded — also useful when re-running the workflow via workflow_dispatch to backfill assets on an old release. Backfill plan: after this lands, re-run the Release workflow on v0.5.0, v0.5.1, v0.6.0 via workflow_dispatch (or push a no-op tag update). Each run will detect the existing release and upload the binaries that were built but never published. Trace: skip
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
2 tasks
avrabe
added a commit
that referenced
this pull request
Apr 30, 2026
…246) Workspace, vscode-rivet, and npm root package versions bumped to 0.7.0. Platform packages stay on the release-npm.yml override path. What's in 0.7.0: - feat(schema): rivet schema migrate Phase 2 (#242) — full git-rebase conflict-resolution UX. Conflict markers in YAML, --continue, --skip, --edit. New MigrationConflict invariant in rivet docs check. - feat(docs-check): subcommand-coverage gate (#241) — walks the live clap CLI tree and asserts each path has an embedded docs topic. Default warn-only; --strict makes it enforcing. - feat(validate): prose-mention-without-typed-link warning (#234, closes #207). - feat(schemas): vv-coverage repo-status type (#232, partial #188). - feat(mutants): canonical cargo-mutants template (#229, closes #185). - docs(pre-commit): canonical 21-hook template (#222, closes #186). - fix(ci): Release workflow now idempotent on existing tag (#244). Known issue: v0.5.0 / v0.5.1 / v0.6.0 release pages have no binary assets attached because the workflow's Create Release step failed on each (race with manual gh release create). The fix in #244 lands in this release; v0.7.0 onward is unaffected. Older releases need a manual gh release upload to backfill. Verified: cargo check, cargo clippy --workspace -- -D warnings, cargo test -p rivet-cli, rivet docs check (clean), rivet docs check --coverage reports 48/81 paths covered (warn-only). Trace: skip
3 tasks
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
1 participant
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.
Problem
The `Create Release` step in `.github/workflows/release.yml` runs:
```bash
gh release create "$VERSION" --title "Rivet $VERSION" --generate-notes release/*
```
This fails with `a release with the same tag name already exists` if a maintainer ran `gh release create` manually right after pushing the tag.
That is exactly what happened on every release in this session — v0.5.0, v0.5.1, and v0.6.0 all hit this failure. Net effect: each release page exists with the auto-generated changelog notes but has no binary / VSIX / SHA256 assets attached.
Fix
Make the step idempotent:
```bash
if gh release view "$VERSION" >/dev/null 2>&1; then
gh release upload "$VERSION" --clobber release/*
else
gh release create "$VERSION" --title "Rivet $VERSION" --generate-notes release/*
fi
```
If the release already exists, upload assets to it. Otherwise create it from scratch. `--clobber` lets re-runs overwrite assets that a previous failed attempt partially uploaded.
Backfill plan
After this lands, the v0.5.0 / v0.5.1 / v0.6.0 releases all need their binaries uploaded. Re-running the Release workflow on each tag via `workflow_dispatch` (or pushing a no-op tag update) will trigger the now-idempotent `Create or update Release` step, which will detect the existing release and upload the binaries that were built but never published.
Test plan
🤖 Generated with Claude Code