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

Offen

#941 erstellt am 24.9.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 3/5
Geschätzter Aufwand: 1-2 Tage
Anfängerfreundlichkeit: 65/100

Issue-Typ: Bug
Klarheit: Klar beschrieben
Aktivitätsstatus: Aktiv
Tech-Stack: github-actions, javascript, ruby
Bereich: backend, ci-cd, tooling

Rechercherichtung

Look at the action's source code, likely in the lib/ or src/ directories, to find where the bundler-cache key is computed. The key currently uses hashFiles('Gemfile.lock'). Understand the GitHub Actions cache API. The fix involves detecting the absence of Gemfile.lock and either skipping the cache or generating a key from Gemfile, *.gemspec, and the commit SHA. Test the change in a fork with a repository that has no Gemfile.lock committed. 'Done' is when a CI run with a lockless workflow correctly installs gems without restoring a stale cache.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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:

skip the bundle cache entirely (fresh bundle install every run —
slower but correct), or
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

Vorherrschende Sprache: JavaScript
Sterne: 990
Forks: 369
Ø Merge: 1 Std. 5 Min.
Gemergte PRs (30 T.): 5

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ruby/setup-ruby

CI failures for mingw builds related to Bundler 4 Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100

ruby/setup-ruby#818 · 6 Kommentare · Erstellt am 10.10.2025
Multiple workflow jobs with same ruby - Bundler cache issue? Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100

ruby/setup-ruby#801 · 3 Kommentare · Erstellt am 08.9.2025
python from msys64 directory gets invoked on windows Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 42/100

ruby/setup-ruby#791 · 3 Kommentare · Erstellt am 30.7.2025
Removing old Ruby builds like Ruby 1.9-2.2 and JRuby 9.1-9.3 and TruffleRuby 19-22 Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100

ruby/setup-ruby#752 · 12 Kommentare · Erstellt am 26.4.2025
bundle install should honor BUNDLE_JOBS configuration Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 38/100

ruby/setup-ruby#673 · 3 Kommentare · 1 Reaktion · Erstellt am 22.11.2024

Alle Issues in ruby/setup-ruby