Ruby rvm/rbenv Shim Conflict - Wrong Ruby Selected in CI
Two Ruby version managers - rvm and rbenv (or chruby) - are both initialized, and they disagree about which Ruby to use. Whichever puts its shim or function first on PATH wins, often not the one you intended.
What this error means
ruby --version prints an unexpected version, and which ruby points at an rvm path when you configured rbenv (or vice versa). A later Bundler step then complains about a Ruby mismatch. The two managers are colliding on PATH.
$ which ruby
/usr/local/rvm/rubies/ruby-3.2.2/bin/ruby # rvm answered
$ rbenv version
3.3.0 (set by /app/.ruby-version) # rbenv expected 3.3.0Common causes
Both managers initialized in the same shell
rvm’s shell function and rbenv’s shims both load (from the image profile or the workflow), and the one earlier on PATH intercepts ruby. The other manager’s selection is silently ignored.
PATH ordering puts the wrong manager first
A system rvm install ahead of ~/.rbenv/shims (or the reverse) means the intended manager never gets to resolve ruby.
How to fix it
Use exactly one version manager
- Pick one manager for the job and do not initialize the other.
- For rbenv, ensure ~/.rbenv/shims is first on PATH and rvm is not sourced.
- For rvm, do not also eval rbenv init in the same shell.
Prefer setup-ruby to sidestep both
ruby/setup-ruby provisions a single Ruby and puts it first on PATH, avoiding manager conflicts entirely.
- uses: ruby/setup-ruby@v1
with:
ruby-version: '3.3.0'
- run: ruby --versionHow to prevent it
- Run only one Ruby version manager per environment.
- Prefer ruby/setup-ruby in CI over hand-managed rvm/rbenv.
- Keep PATH ordering explicit so the intended manager leads.