GeezerVison is showing github.com — Retry pinned bundler installs in the e2e legs by mikolalysenko · Pull Request #1854 · SocketDev/socket-patch
Conversation
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
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
#1828 moved hosted-e2e's bundler install off setup-ruby's `bundler:`
input, which runs one bare `gem install` with no retry, after a single
failed TCP connect to rubygems.org evicted #1813 from the merge queue.
The shared e2e steps still installed every 2.x/4.x pinned bundler (and
e2e_gem's 2.5 floor) the same way: the bundler 4.0.21 gem leg in the
merge-queue `e2e` job, plus six legs in nightly e2e-extended/e2e-full.
Set `bundler: 'none'` and install every pinned bundler through
scripts/gem-install-retry.sh, folding in the existing 1.x step. A
two-part version keeps the `~> X.Y.0` requirement setup-ruby derived
for it; a three-part pin stays exact.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_011f9aeRXHaoEzZbpeYNu2xM
cursor[bot] reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ 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.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
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
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
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
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
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
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
[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
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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:
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
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Oct 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[agent] Reviewed 09da545011ac759eac370724d3e3df2ca44c5aca. Checked pinned Bundler requirements, install gating and activation against the matrix. No major correctness issues found. Validation: source and regression-test review plus the available exact-head CI checks; no local test pass is claimed.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Labels
ci-janitor
Opened by the CI janitor routine (flakes, redundant tests, CI perf)
Ready for review
Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
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.
|
Wenxin Jiang (Wenxin-Jiang)
left a comment