Skip to content

Create the release tag in the workflow, from a commit and a version - #3055

Merged
soutaro merged 2 commits into
masterfrom
claude/gha-tag-push-method-cp52p2
Jul 30, 2026
Merged

Create the release tag in the workflow, from a commit and a version#3055
soutaro merged 2 commits into
masterfrom
claude/gha-tag-push-method-cp52p2

Conversation

@soutaro

@soutaro soutaro commented Jul 30, 2026

Copy link
Copy Markdown
Member

Pushing a tag needs credentials a cloud development environment does not have, so Release gems creates the tag itself rather than it being pushed by hand beforehand.

Dispatch it with the commit being released and the version that commit declares. Everything is built from the commit, and the version is the same fact stated a second time: the run stops before anything is built unless it matches RBS::VERSION at that commit and the section CHANGELOG.md starts with. The tag is created once both gems are known to build and run, and before anything is published.

dry_run builds and checks both gems and stops there — no tag, nothing pushed to RubyGems, no GitHub release — which is how the build is exercised without releasing anything.


Generated by Claude Code

claude added 2 commits July 30, 2026 21:55
Pushing a tag needs credentials that a cloud development environment does
not have, so the tag is created by `Release gems` rather than by hand
before it.

The workflow now takes the commit being released and the version that
commit declares. Everything is built from the commit, so the run no
longer depends on where `master` is when it starts, and the version is
the same fact stated a second time: the run stops before anything is
built unless it matches `RBS::VERSION` at that commit and the section
CHANGELOG.md starts with. Releasing the wrong commit, or the right one
under the wrong name, is a failed run rather than a gem to yank.

The tag is created once both gems are known to build and run, and before
anything is published, so the reversible step still comes before the
irreversible one. What it names is decided by the checkout, so nothing
rests on it existing first, which is what let it move after the build.

`github.ref_type == 'tag'` used to be what separated a release from a
build, and a branch dispatch was the dry run. The ref no longer decides
anything, so `dry_run` is an explicit input: it builds and checks both
gems and stops before the tag.

`rake gem:check_release[X.Y.Z]` and `rake gem:tag` are the two steps the
workflow runs, so both are also available locally.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BvSmN7ats6HGEyeT7VEbau
A patch release can be cut from a release branch, which is not an
ancestor of the default branch, so requiring one rejected a release that
is perfectly normal.

What is left is that some branch contains the commit -- a commit no
branch leads to is one that cannot be found again -- and the branches
that do are printed, so the log says where the release came from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BvSmN7ats6HGEyeT7VEbau
@soutaro
soutaro force-pushed the claude/gha-tag-push-method-cp52p2 branch from 7b6e4a1 to 45c9bb6 Compare July 30, 2026 12:55
@soutaro
soutaro enabled auto-merge July 30, 2026 12:56
@soutaro
soutaro added this pull request to the merge queue Jul 30, 2026
Merged via the queue into master with commit e834ace Jul 30, 2026
25 checks passed
@soutaro
soutaro deleted the claude/gha-tag-push-method-cp52p2 branch July 30, 2026 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants