-
-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider bundle groups in cache keys #176
Comments
Right, so the Gemfile.lock is the same no matter which One concern here is that it might be useful to install all gems in a first job, and then other jobs (with Including their values in the key automatically also makes sense, is probably more intuitive, and would avoid having any extra gems in |
@artygus Are you still interested to make a PR for this? |
@eregon whoops! I totally forgot about this one, I'll try to come up with a PR next week. I'll keep you posted. |
It's possible to add or skip certain gem groups with
with:
andwithout:
config options (via correspondingBUNDLE_WITH
andBUNDLE_WITHOUT
env variables) which might set an incomplete cache. It's because currently cache key includes the whole Gemfile.lock contents. I wonder if it's a good idea to add values of aforementioned env variables to the cache key?For example my current use case is two github actions: one for specs that requires all gems and another is linter action that only requires
pronto
specific stuff. Example Gemfile:Action for linter run involves two env vars:
If Gemfile.lock changes and linter action runs quicker it would set cache that only includes
pronto
gems, and specs action would install rails and bunch of other gems all over again on every run.With a recent introduction of cache-version config in #175 it's not such a big problem, I could just set a custom cache-version prefix to linter action though 🤔
If this proposal makes sense I'd be happy to submit a PR.
The text was updated successfully, but these errors were encountered: