[Mikola Lysenko (mikolalysenko)]

Problem

ruby/setup-ruby's bundler: input installs bundler with one bare gem install. RubyGems has no retry of its own. On 2026-10-29 at 13:34 UTC a single SocketError: Failed to open TCP connection to rubygems.org:443 in hosted-e2e's Setup Ruby step failed merge_group run 40882178298 and evicted #1813 from the queue.

#1828 fixed that for hosted-e2e only. The shared &e2e-steps still install the pinned 2.x/4.x bundlers, and e2e_gem's 2.5 floor, through that same bare install:

• Merge queue / PRs: the e2e job's gem leg (ruby: '3.4', bundler: '4.0.21').
• Nightly / dispatch: e2e-extended (bundler 2.1.4, 2.2.33, 2.5.23, 2.6.9, 4.0.15) and e2e-full (2.7.2).

One rubygems.org blip on the merge-queue leg evicts an entry in exactly the same way as #1813.

Fix

• Setup Ruby always uses bundler: 'none'.
• The existing "Install Bundler 1.x" step becomes "Install Bundler". It runs for every leg that pins a bundler, plus e2e_gem, and goes through scripts/gem-install-retry.sh (4 attempts, growing pause).
• The version requirement matches what setup-ruby used: a two-part version like 2.5 becomes ~> 2.5.0, and a three-part pin stays exact.
• "Select the pinned Bundler" (BUNDLER_VERSION) is unchanged, so every leg still runs exactly its pinned bundler.

Proof

• scripts/gem-install-retry.sh bundler -v "~> 2.5.0" --no-document installs bundler-2.5.23 locally (Ruby 3.3.6).
• The requirement mapping gives 2.5 → ~> 2.5.0, 4.0.21 → 4.0.21, 2.1.4 → 2.1.4 and 1.17.3 → 1.17.3.
• zizmor reports the same 54 findings before and after. actionlint (v1.7.7) reports the same 37 pre-existing anchor-parsing complaints before and after.
• The PR's own e2e gem leg (bundler 4.0.21) exercises the new step. The nightly legs share the same step.

Where tests run

Nothing is removed or moved. No required-check names change.

---

Generated by Claude Code

---

Note

Low Risk
CI-only workflow change to bundler installation; no application code or required-check names change, and pinned versions plus BUNDLER_VERSION selection are preserved.

Overview
E2e gem/bundler legs no longer install Bundler through ruby/setup-ruby. Setup Ruby now always passes bundler: 'none', and a renamed Install Bundler step runs for every leg that pins matrix.bundler plus e2e_gem, calling scripts/gem-install-retry.sh instead of setup-ruby’s single-shot gem install.

The step maps version pins the same way setup-ruby did: two-part pins like 2.5 become ~> 2.5.0, three-part pins stay exact. Select the pinned Bundler (BUNDLER_VERSION) is unchanged, so runtime bundler selection behavior is the same—only the install path gains retries for rubygems.org flakes on merge-queue and nightly e2e rows.

^{Reviewed by Cursor Bugbot for commit 09da545. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 09da545. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Two e2e legs failed: e2e_redirect_pnpm_build and e2e_vendor_pypi_build 0.12.17. Both failed with "The self-hosted runner lost communication with the server", 20:52–21:02 UTC. Neither leg runs the Ruby/bundler steps this PR changes. This is the ongoing Depot runner incident tracked in #1660, which hit main and the merge queue in the same window. The leg this PR changes, e2e (ubuntu-latest, e2e_redirect_gem_build e2e_vendor_gem_build, 3.4, 4.0.21), passed, with Install Bundler succeeding. I will re-run the failed jobs once after the run finishes.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

The single re-run of the lost legs is done. e2e_vendor_pypi_build 0.12.17 now passes. e2e_redirect_pnpm_build lost its runner again at 21:20 (job 123730461155, same annotation), so it is still red only because of the Depot incident in #1660. No code change is needed here. The leg needs one more run once Depot recovers.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review at 09da545011ac759eac370724d3e3df2ca44c5aca.

• CI: 32/32 run checks green (19 skipped by path filters), mergeable, no conflicts.
• Bugbot: reviewed 09da545, no findings.
• Reviewer note: this builds on Retry CI bundler installs on rubygems.org blips #1828 (already on main): it moves the e2e legs' bundler install (not just 1.x) through scripts/gem-install-retry.sh, mapping a two-part pin like 2.5 to ~> 2.5.0 as setup-ruby did. Merges cleanly with current main.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] Labeled Ready for review at 09da545.

• CI: all 51 checks on 09da545 passed or were skipped (32 success, 19 skipped). Two e2e legs had lost their runners; the one allowed re-run passed.
• Bugbot: reviewed 09da545 with no findings, and no threads are open.
• Reviewer note: this only changes CI. setup-ruby no longer installs bundler (bundler: 'none'). Every gem leg now installs it through scripts/gem-install-retry.sh. A two-part pin such as 2.5 becomes ~> 2.5.0, which matches what setup-ruby used to install; a three-part pin stays exact. The step runs under the same if: as Setup Ruby.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: Pinned bundler installs in the e2e legs went through setup-ruby's single gem install, which never retries, so a transient rubygems.org failure turned a leg red. Setup Ruby now gets bundler: 'none', and a separate step installs the pinned bundler through scripts/gem-install-retry.sh (4 attempts). It uses the same ~> X.Y.0 constraint setup-ruby builds for a two-part version, and an exact pin for a three-part one.

Risk: low. This is a CI workflow change only. The retry loop exits 1 after the last attempt, because gem install runs inside if and is therefore not killed by set -e. The only interpolated value is matrix.bundler, a static matrix value passed via env:. Every leg with a bundler pin runs on ubuntu, so no Windows shell is involved.

Look here:

• ci.yml:1589: Setup Ruby, with the same if: as before
• ci.yml:1611-1621: the new install step
• gem-install-retry.sh:20-31: the retry loop

Verified: I read the diff and the script, and checked that Setup Ruby and the install step share the same condition, so no leg loses its bundler. CHANGELOG.md is untouched. CI is green on 09da545 (32 passed, 19 skipped, ci-ok and clippy both green). Bugbot found no new issues.

Changes I made: none.

Open questions: none. Two notes. No current matrix row uses suite: e2e_gem, so that arm of the condition never fires. If a Windows bundler leg is ever added, the step will need --force the way setup-ruby uses it.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code