You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multiple workflow jobs with same ruby - Bundler cache issue? #801
Puma runs several workflow files, and there is overlap between the Ruby versions. For example, Ruby head is used in both the Puma CI workflow and a workflow that tests with turbo-rails. The turbo-rails workflow installs Rails.
Recently I noticed logs for the CI run loading a 'close key' match cache, and it logged removing all the Rails gems. Or, with multiple jobs with matching Ruby vesions, the cache may have .misses'.
Recently I noticed logs for the CI run loading a 'close key' match cache, and it logged removing all the Rails gems.
In theory that should be fine, because it would just create a new cache from the existing cache. Did it cause any issue?
Do you have any log of that?
I suppose we could include the workflow name (ideally the YAML file name and not user-provided name) into the cache key, probably that's a sensible solution, PR welcome.
Copying it here for posterity.
Looks fine, though the output is somewhat confusing with Cache hit for but actually using the cache from another key.
Also Print lockfile took 21.08 s is a bit confusing, that's probably the time for the whole Bundler section.
Activity
eregon commentedon Sep 9, 2025
In theory that should be fine, because it would just create a new cache from the existing cache. Did it cause any issue?
Do you have any log of that?
I suppose we could include the workflow name (ideally the YAML file name and not user-provided name) into the cache key, probably that's a sensible solution, PR welcome.
MSP-Greg commentedon Sep 9, 2025
No. Just seemed like a waste. I guess it's a distinction between storing more caches on GHA or hitting RubyGems.org more...
Example, which will disappear sometime soon.
http://github.com/puma/puma/actions/runs/17436777368/job/49508712527#step:5:138
I'll look into a PR.
eregon commentedon Sep 10, 2025
Copying it here for posterity.
Looks fine, though the output is somewhat confusing with
Cache hit forbut actually using the cache from another key.Also
Print lockfile took 21.08 sis a bit confusing, that's probably the time for the whole Bundler section.