Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#941 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
65/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, javascript, ruby
Domaine
backend, ci-cd, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
JavaScript
Étoiles
990
Forks
369
Merge moyen
1 h 5 min
PR mergées (30 j)
5

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ruby/setup-ruby

Toutes les issues de ruby/setup-ruby

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.