bundler-cache with no Gemfile.lock: constant cache key restores stale vendor/bundle (broken gem payloads)

[ronaldtse]

Summary

With bundler-cache: true and no Gemfile.lock committed (lockless
workflow, e.g. lock deliberately untracked), the bundle cache key
degenerates: hashFiles('Gemfile.lock') is empty, so the
vendor/bundle cache key becomes effectively constant across runs and
dependency changes. Jobs restore a stale or partially-invalid
vendor/bundle from an arbitrary earlier run. In our case the restored
rspec-support gem was missing lib/rspec/support/source.rb, and the
run then crashed fatally inside rspec's summary formatter
(LoadError), hiding all real test failures.

Observed on

• ruby/setup-ruby@v1, bundler-cache: true
• Repository with Gemfile.lock in .gitignore (CI re-resolves deps)
• ubuntu 22.04, Ruby 3.3.12
• run: metanorma/uniword PR CI, 2026-09-24

Expected

When no Gemfile.lock exists, either:

1. skip the bundle cache entirely (fresh bundle install every run —
   slower but correct), or
2. derive the cache key from Gemfile + *.gemspec hashes and
   git rev-parse HEAD (or the run id), so every dependency change
   produces a distinct cache entry and stale bundles are never
   restored.

A warning (::warning::) that the bundle cache was skipped/derated
for lockless workflows would also make the failure mode diagnosable.

Workaround we applied

rm -rf vendor/bundle in a pre-setup step (forces pristine install).

Versions

• ruby/setup-ruby@v1 (current main as of 2026-09-24)
• Bundler 4.0.x

[ntkme]

First, you have a misunderstanding on how cache save/restore work, that the save key is a full string with hash of lockfile (it get generated even if you don't have one), and restore key is only a key prefix, that it does not have the hash of lockfile in it:

setup-ruby/bundler.js

Lines 195 to 197 in 762794c

	const key = `${baseKey}-${await common.hashFile(lockFile)}`
	// If only Gemfile.lock changes we can reuse part of the cache, and clean old gem versions below
	const restoreKeys = [`${baseKey}-`]

When cache is restored, it looks up any previous cache with the same common prefix and pick the most up to update one if there isn't an exact match.

---

I don't have Gemfile.lock in my repo and I can see that cache get restored and partially reused as expected:

https://github.com/sass-contrib/sass-embedded-host-ruby/actions/runs/35266539820/job/105355033938

Cache restored successfully
Found cache for key: setup-ruby-bundler-cache-v6-macos-16-arm64-ruby-3.4.10-wd-/Users/runner/work/sass-embedded-host-ruby/sass-embedded-host-ruby-with--without--only--Gemfile.lock-5e4899cfbe57bcd8bf5223e3ca6ad0f39457bf1a2733eb34eb7362b961d28c44
/Users/runner/hostedtoolcache/Ruby/3.4.10/arm64/bin/bundle install --jobs 3
Fetching gem metadata from https://rubygems.org/...........
Fetching bigdecimal 4.1.3
Fetching rubocop 1.91.0
Installing bigdecimal 4.1.3 with native extensions
Installing rubocop 1.91.0
Bundle complete! 7 Gemfile dependencies, 29 gems now installed.
Bundled gems are installed into `./vendor/bundle`
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details
/Users/runner/hostedtoolcache/Ruby/3.4.10/arm64/bin/bundle clean
Removing bigdecimal (4.1.2)
Removing rubocop (1.90.0)
Saving cache
/opt/homebrew/bin/gtar --posix -cf cache.tzst --exclude cache.tzst -P -C /Users/runner/work/sass-embedded-host-ruby/sass-embedded-host-ruby --files-from manifest.txt --delay-directory-restore --use-compress-program zstdmt
Sent 9980294 of 9980294 (100.0%), 9.5 MBs/sec

[ronaldtse]

Thank you for the detailed correction, which identifies the misunderstanding in the original report.

The cache save key is a complete string that incorporates a hash of the lockfile, and the restore step performs a prefix lookup that selects the most recent matching entry, so lockless repositories receive functional cache restores by design.

The failure that motivated this report originated on our side: our workflow restored a partially valid vendor bundle, and the underlying cause has since been fixed in our repository. The report is therefore closed as not a defect in setup-ruby, and the unnecessary maintenance burden is regretted.

Thank you for the correction and for the maintenance of setup-ruby.