Skip to content

Release the gems from a workflow - #3047

Merged
soutaro merged 1 commit into
masterfrom
build-gems-workflow
Jul 30, 2026
Merged

Release the gems from a workflow#3047
soutaro merged 1 commit into
masterfrom
build-gems-workflow

Conversation

@soutaro

@soutaro soutaro commented Jul 30, 2026

Copy link
Copy Markdown
Member

Building both gems and pushing them by hand — rake release for the ruby one, a Docker image for the java one because it needs the WASI SDK — moves to a Release gems workflow: dispatched against a vX.Y.Z tag it builds both gems, installs the java one on JRuby and parses with it, pushes both to RubyGems through trusted publishing, and publishes the GitHub release.

A release is now a pull request, a tag, and one workflow run; docs/release.md is rewritten around that, including what the three kinds of release (X.Y.Z, .pre.N, .dev.N) each get written up as.

@soutaro
soutaro force-pushed the build-gems-workflow branch from 15bbf51 to be56733 Compare July 30, 2026 03:32
@soutaro soutaro added the skip-changelog Skip PRs in CHANGELOGs label Jul 30, 2026
`docs/release.md` had the maintainer build both gems locally and push them by
hand: `rake release` for the `ruby` one, and a Docker image for the `java` one
because it needs the WASI SDK to compile `rbs_parser.wasm`. That is a lot of
laptop for something that has to be reproducible, and it puts the RubyGems
credentials of whoever runs it in the path.

`Release gems` does it instead. Dispatched against a `vX.Y.Z` tag it builds
both gems, checks them, pushes them to RubyGems through trusted publishing, and
publishes the GitHub release. A release is now a pull request, a tag, and one
workflow run.

The `java` gem is built on CRuby rather than in the JRuby image: the platform
comes from `RBS_PLATFORM`, not from the engine running `gem build`, so all the
image was providing is the WASI SDK -- which the `wasm` and `jruby` workflows
already install directly. JRuby is still needed to *run* the result, so the
workflow installs the built gem on JRuby and parses with it. That is the check
metadata cannot make: a stale or broken wasm module only shows at require time.

Publishing is ordered so that the reversible step always comes first. The tag
is created before the workflow runs; the artifacts are uploaded before the
push, so a failed push still leaves the gems behind; and the GitHub release
comes last, so a failed push never announces a release that has no gems.

The trusted publisher has no environment, so the dispatched ref is the only
thing deciding what gets published. The workflow refuses to publish unless the
tag matches `RBS::VERSION`, and dispatching against a branch builds and stops.

`gem:gh_release` takes the notes from the topmost CHANGELOG.md section and is
skipped for `.dev.N` versions, which are cut from the development line and are
not written up. It reads the file as UTF-8 explicitly: the default external
encoding follows the locale, which is C on the runners.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@soutaro
soutaro force-pushed the build-gems-workflow branch from d7ac3da to 38f6990 Compare July 30, 2026 07:31
@soutaro soutaro changed the title Build both release gems from a workflow dispatch Release the gems from a workflow Jul 30, 2026
@soutaro
soutaro marked this pull request as ready for review July 30, 2026 07:31
@soutaro
soutaro enabled auto-merge July 30, 2026 07:33
@soutaro
soutaro added this pull request to the merge queue Jul 30, 2026
Merged via the queue into master with commit f6d395d Jul 30, 2026
26 checks passed
@soutaro
soutaro deleted the build-gems-workflow branch July 30, 2026 07:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

skip-changelog Skip PRs in CHANGELOGs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant