Release workflow: publish to RubyGems.org from GitHub Actions - #23
Merged
Merged
Conversation
Mirrors the logtail-js and logtail-python release workflows. main requires pull requests, so the version bump stays a pull request and the workflow tests, builds, pushes the gem, tags and creates the GitHub release. Every push touching the workflow file is a dry run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The environment restricts deployments to main and has no required reviewers, so anyone who can dispatch the workflow can release. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The GitHub Actions app may bypass the pull request requirement of main now, so the workflow takes patch, minor and retry inputs like the logtail-js and logtail-python ones and pushes the version commit and the tag itself. Dry runs bump in place without committing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The shared rubygems.org account requires a one-time code for API pushes, which no workflow can supply: the first logtail release stopped at gem push. The publish job now exchanges its OIDC token with RubyGems.org for a short-lived key, like the npm packages do. Dry runs perform the exchange too, so a workflow change proves the trusted publisher setup before it is merged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
PetrHeinz
had a problem deploying
to
rubygems
September 30, 2026 16:15 — with 
GitHub Actions
Failure
GitHub Actions
Failure
The rubygems environment admits main only, so a publish job started from another branch is rejected before its first step. Dry runs from other branches stop after the build; the push that merges a workflow change into main performs the token exchange. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
retry insisted that the version commit is HEAD, but main moves on as soon as anything else is merged, as happened between the failed logtail 0.1.18 release and its retry. The retry now checks out the tag of the version in lib/*/version.rb and rebuilds that commit. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
Mirrors the Release workflow of logtail-js and logtail-python: Actions → Release → Run workflow from
main, pickpatchorminor, and the workflow runs the tests, bumps the version inlib/*/version.rb, builds the gem, commitsvX.Y.Z, tags it, pushes both, pushes the gem to RubyGems.org and creates a GitHub release with generated notes.retryfinishes a release that failed after the version commit was pushed: it bumps nothing, rebuilds the tagged commit and only does what is still missing.Authentication is trusted publishing (OIDC), like the npm packages: no API key is stored anywhere, the gem on rubygems.org trusts this workflow file run from this repository in the
rubygemsenvironment, and the shared account's multi-factor authentication stays as it is (its "UI and API" level rejects pushes with an API key, which is what stopped the first logtail release). One-time setup on rubygems.org, signed in as the gem's owner:logtail-rack→ Trusted publishers → GitHub Actions with ownerlogtail, repositorylogtail-ruby-rack, workflowrelease.yml, environmentrubygems. TheRUBYGEMS_CREDENTIALSsecret is unused and can be deleted.The version commit is pushed with the workflow's own token.
mainrequires pull requests, so the GitHub Actions app is among the actors allowed to bypass that requirement (Settings → Branches → themainrule), and the workflow header says so. Therubygemsenvironment exists with deployment branches limited tomainand no required reviewers, so anyone who can dispatch the workflow can release. Add reviewers there if releases should need an approval.Dry run: every push that touches
.github/workflows/release.ymlbumps in place, runs the tests and builds the gem, without committing or publishing anything. Therubygemsenvironment only admitsmain, so the token exchange with RubyGems.org runs in dry runs onmain: the push that merges this pull request triggers one, and it is red until the trusted publisher exists. A dry run can also be dispatched frommainat any time. Pushing the version commit itself is only exercised by the first real release.🤖 Generated with Claude Code