fix(release): bypass rubygems/release-gem to avoid bundler/securerandom clash

Both prior v1.0.0 publish attempts (workflow runs 25679243892 and
25679904207) failed with:

  You have already activated securerandom 0.2.2, but your Gemfile
  requires securerandom 0.4.1.

Diagnosis: `rubygems/release-gem` calls `bundle exec rake release`
internally, with an attestation-patch loaded via RUBYOPT. That
patch (or something it requires) loads securerandom *before*
bundler resolves the Gemfile. Ruby 3.2.11 ships securerandom 0.2.2
as a default gem, which gets activated. Bundler then tries to
resolve to the newer securerandom that a transitive dep wants and
hits the activated-spec conflict.

Setting `bundler: latest` (PR #18) didn't help — same failure on
bundler 4.0.11. The conflict is a Ruby-runtime / default-gem issue,
not a bundler version issue.

Fix: do the build + push directly. Replace `rubygems/release-gem`
with `rubygems/configure-rubygems-credentials` (does the OIDC
handshake + writes ~/.gem/credentials), then `gem build` + `gem
push`. No `bundle exec` on the push path means no
default-gem activation, no conflict.

We lose the SLSA attestation that `release-gem` would have added —
worth picking back up later when the underlying tooling is less
fragile. For 1.0.0 the gem just needs to be on RubyGems.

Reverts the `bundler: latest` from PR #18 since it's no longer
needed (and pinning bundler when we don't need to is gratuitous).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: jathayde

.github/workflows/release.yml

@@ -52,12 +52,6 @@ jobs:
         uses: ruby/setup-ruby@c4e5b1316158f92e3d49443a9d58b31d25ac0f8f # v1 branch head as of 2026-05-11
         with:
           ruby-version: "3.2"
-          # Ruby 3.2.11 ships with bundler 2.4.19, which doesn't handle
-          # the `securerandom` default-gem conflict that surfaces when a
-          # transitive dep requires a newer securerandom than the one
-          # the stdlib ships. `bundler: latest` resolves it (>= 2.5).
-          # The v1.0.0 first-publish run caught this — see PR #18.
-          bundler: latest
           bundler-cache: true
 
       # Belt-and-braces: refuse to publish a tag whose version doesn't
@@ -84,10 +78,21 @@ jobs:
       - name: Run the test suite
         run: bundle exec rspec
 
-      # Official RubyGems trusted-publisher action. Exchanges the
-      # GitHub OIDC token for a short-lived RubyGems API key, builds
-      # the gem, and pushes. Action infers the gemspec from the repo
-      # root and only pushes if rubygems.org accepts the OIDC claim
-      # against a registered (or pending) trusted publisher.
-      - name: Build and push to RubyGems.org
-        uses: rubygems/release-gem@6317d8d1f7e28c24d28f6eff169ea854948bd9f7 # v1.2.0
+      # Two-step publish — exchange the GitHub OIDC token for a
+      # short-lived RubyGems API key, then `gem build` + `gem push`
+      # directly. We don't use rubygems/release-gem (the "all in one"
+      # wrapper) because it invokes `bundle exec rake release` under
+      # an attestation-patch RUBYOPT, which activates the stdlib's
+      # securerandom default gem before bundler resolves and conflicts
+      # with any transitive dep that wants a newer securerandom — what
+      # tanked the v1.0.0 first-publish attempts (workflow runs
+      # 25679243892 and 25679904207). The direct approach avoids
+      # bundler entirely on the push path.
+      - name: Configure RubyGems trusted-publisher credentials
+        uses: rubygems/configure-rubygems-credentials@762a4b77c3300434bb57c7ce80b20e36231927aa # v2.0.0
+
+      - name: Build gem
+        run: gem build guardrails.gemspec
+
+      - name: Push to RubyGems.org
+        run: gem push guardrails-*.gem