Skip to content

Add release workflow: auto-create a GitHub Release on version bump - #73

Merged
jmnote merged 1 commit into
mainfrom
chore/release-workflow
Sep 6, 2026
Merged

Add release workflow: auto-create a GitHub Release on version bump#73
jmnote merged 1 commit into
mainfrom
chore/release-workflow

Conversation

@jmnote

@jmnote jmnote commented Sep 6, 2026

Copy link
Copy Markdown
Owner

Summary

New .github/workflows/release.yml: on every push to main, compares extension.json's version field 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.0 releases (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

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread .github/workflows/release.yml Outdated
echo "Release $TAG already exists, skipping."
exit 0
fi
gh release create "$TAG" --title "$TAG" --generate-notes

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .github/workflows/release.yml Outdated
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 "")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
@jmnote
jmnote force-pushed the chore/release-workflow branch from 9b6616a to 28525db Compare September 6, 2026 06:31
@jmnote
jmnote merged commit 34859c8 into main Sep 6, 2026
1 check passed
@jmnote
jmnote deleted the chore/release-workflow branch September 6, 2026 06:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant