Self-Healing CI: Auto-Retrying "Could not fetch specs from rubygems.org"
Bundler reporting "Could not fetch specs" has already retried internally four times: the Gemfile is fine and the specs are there, the transport was not.
The problem
A bundle install fails fetching the specs index from rubygems.org. The Gemfile and lockfile are valid. Bundler retries the fetch four times on its own before giving up, so by the time the job fails the failure has already persisted through several attempts inside the command.
Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/Why it happens
rubygems.org is fronted by a CDN, and the intermittent failures usually seen in CI are edge or dual-stack routing hiccups rather than the origin being down. They clear on the order of seconds.
Because Bundler prints its internal retry counter, the log shows the failure several times over, which reads like a hard outage. It is the same transient being reported once per attempt.
The manual fix
Manual mitigations for a Bundler network failure:
- Re-run the job to retry the fetch.
- Raise Bundler's own retry count so brief blips are absorbed inside the command.
- Mirror rubygems.org internally so CI is not dependent on the public endpoint.
bundle install --retry 5 --jobs 4How this gets automated
The useful signal is that Bundler exhausted its own retries: a failure that survives four in-command attempts will not be fixed by a fifth issued immediately, but it very often clears given a few seconds of separation. A self-healing pipeline retries at the step level with real backoff between attempts, which is a different thing from Bundler retrying tightly inside one command, and is why it succeeds where the built-in retry did not.