Skip to content

Consider bundle groups in cache keys #176

@artygus

Description

@artygus

It's possible to add or skip certain gem groups with with: and without: config options (via corresponding BUNDLE_WITH and BUNDLE_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:

source "https://rubygems.org"

gem "rails", "~> 6.1"
# ... other gems ...

group :linter, optional: true do
  gem "pronto"
  gem "pronto-rubocop"
end

group :development, :linter do
  gem "rubocop", require: false
  gem "rubocop-rails", require: false
end

Action for linter run involves two env vars:

env:
  BUNDLE_WITH: linter
  BUNDLE_WITHOUT: default:development:test

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions