Add release workflow: auto-create a GitHub Release on version bump - #73
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9b6616a2b0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| echo "Release $TAG already exists, skipping." | ||
| exit 0 | ||
| fi | ||
| gh release create "$TAG" --title "$TAG" --generate-notes |
There was a problem hiding this comment.
Target the release tag at the triggering commit
If another push reaches main before this step executes, the tag can point at the newer commit rather than the commit whose extension.json supplied TAG. The installed gh release create --help states that a missing tag is created “from the latest state of the default branch” unless --target is supplied, so concurrent or queued runs can permanently associate a version with the wrong source; pass the triggering SHA as the target.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed — added --target "$GITHUB_SHA" to gh release create so the tag is pinned to the commit that triggered this run, not whatever main happens to be at execution time.
| id: version | ||
| run: | | ||
| current=$(jq -r .version extension.json) | ||
| previous=$(git show HEAD^:extension.json 2>/dev/null | jq -r .version 2>/dev/null || echo "") |
There was a problem hiding this comment.
Compare the version with the pre-push commit
When one push contains a version-bump commit followed by any commit that leaves extension.json unchanged, HEAD^ already contains the new version, so this comparison reports changed=false and the push never creates its release. Compare the final version with the push event's pre-push SHA (and fetch that commit as needed) so multi-commit pushes are handled.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed — now compares against git show ${{ github.event.before }}:extension.json (the state before this whole push) instead of HEAD^, so a push carrying more than one commit is handled correctly even if a later commit in the same push doesn't touch extension.json. Bumped checkout to fetch-depth: 0 so that commit is always available.
On every push to main, compares extension.json's version field against its value before the push (github.event.before, not just HEAD^ — a push can carry more than one commit) and, if it changed, tags and creates a GitHub Release (vX.Y.Z, with auto-generated notes from merged PRs) for that version, targeted at the triggering commit so a race with another push landing on main first can't point the tag at the wrong commit. Automates what has so far been done by hand after each version bump (matches the existing v0.9.0/v0.10.0/v0.11.0 releases: same tag naming, same --generate-notes-style body). Guards against re-creating a release that already exists (idempotent on workflow re-runs or a version merged more than once). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
9b6616a to
28525db
Compare
Summary
New
.github/workflows/release.yml: on every push tomain, comparesextension.json'sversionfield against the previous commit's. If it changed, tags and creates a GitHub Release (vX.Y.Z, with auto-generated notes from merged PRs) for that version.This automates what's so far been done by hand after each version bump — matches the existing
v0.9.0/v0.10.0/v0.11.0releases (same tag naming, same--generate-notes-style body), so it should slot in without changing how releases look.Guards against re-creating a release that already exists (idempotent on workflow re-runs, or a version merged more than once).
🤖 Generated with Claude Code