Ruby ".ruby-version vs CI Ruby" mismatch in builds

Your repo pins a Ruby in .ruby-version, but the CI step that installs Ruby was told a different version (or hardcoded one). The two disagree, so tools that honor .ruby-version pick one interpreter while the rest of the job uses another.

What this error means

Builds behave inconsistently or fail with a version-related error: a gem compiled for one Ruby, a bundler/version mismatch, or rbenv selecting a version the install step never provisioned.

# .ruby-version
3.3.1

# workflow installed a different one
- uses: ruby/setup-ruby@v1
  with:
    ruby-version: '3.2'   # <- disagrees with .ruby-version

Common causes

The setup step hardcodes a version that differs from .ruby-version

A literal ruby-version in the workflow overrides the file, so the running Ruby is not the one the repo declares.

A version manager reads .ruby-version while CI used another Ruby

rbenv/chruby honor .ruby-version, but the job already activated a different interpreter, producing two competing selections.

How to fix it

Let the setup step read .ruby-version

Point the installer at the file so there is a single source of truth.

- uses: ruby/setup-ruby@v1
  with:
    ruby-version: .ruby-version
    bundler-cache: true

Reconcile the file with the intended version

1. Decide the canonical Ruby version for the project.
2. Set .ruby-version to it and remove any conflicting hardcoded version in CI.
3. Re-run and confirm ruby -v matches the file.

How to prevent it

• Use .ruby-version as the single source of truth and have CI read it.
• Avoid hardcoding a Ruby version in the workflow when a .ruby-version file exists.
• Verify ruby -v early in the job matches the pinned file.

Related guides