Skip to content
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

Make ConfigLoaderResolver#gem_config_path consider gem version #8080

Open
roberts1000 opened this issue Jun 1, 2020 · 1 comment
Open

Make ConfigLoaderResolver#gem_config_path consider gem version #8080

roberts1000 opened this issue Jun 1, 2020 · 1 comment
Labels
stale Issues that haven't been active in a while

Comments

@roberts1000
Copy link
Contributor

Is your feature request related to a problem? Please describe.

ConfigLoaderResolver#gem_config_path doesn't always know which version of an inherited gem to load. My org keeps our rubocop configuration inside a gem and we load it in the standard way:

inherit_gem:
  our_gem: config/rubocop.yml

There's nothing that tells rubocop which version of our_gem to load. Up until rubocop
0.85.0, rubocop picked the latest version of our_gem. 0.85.0 was enhanced to use the version that bundler resolves. This is a great improvement, but it only helps when our_gem is listed in the Gemfiles. We typically don't include our_gem, or rubocop, in our project Gemfiles because we want our CI pipeline to define the versions that should be used ... not the projects.

Our CI pipeline executes rubocop _the_desired_version_ to invoke the accepted version of rubocop, and we control our_gem by trying to ensure we only ever have the desired version installed (so it can be the only one chosen). This almost never works. Some way, some how, the latest version of our_gem manages to get installed on the CI server. Once it's there, problems quickly start. Consider this scenario:

  1. Our CI pipeline is configured to use our_gem version X1.
  2. We release our_gem version X2, but don't install it on the CI pipeline.
  3. Teams are notified that the new version is available and they are given time to review and request changes.
  4. During the review time, someone mistakenly installs our_gem in their Gemfile, runs a build on the CI pipeline and installs our_gem X2 on the CI server for everyone else.
  5. The next time rubocop runs for someone on the CI server, it uses the configuration from X2 (because rubocop always loads the configuration from the latest version of our_gem).
  6. Builds start breaking for multiple project teams because the older version of rubocop doesn't understand the new configuration. Or, potentially even worse, rubocop doesn't break and we run the incorrect configuration without realizing it.

Describe the solution you'd like

It would be amazing if there was some way to give rubocop more information about the version of the custom gem that should be used. Perhaps something like:

inherit_gem:
  our_gem: config/rubocop.yml
  version: x.y.z

Ultimately, it would be best if we could pass this info to rubocop via an environment variable since our goal is to avoid having individual projects declare their own our_gem versions.

inherit_gem:
  our_gem: config/rubocop.yml
  version: ENV["OUR_GEM_VERSION"]

Describe alternatives you've considered

A simpler alternative would be to establish a standard environment variable like INHERITED_GEM_VERSION. gem_config_path could use it to help determine the version of our_gem to select.

@stale
Copy link

stale bot commented Nov 29, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the stale Issues that haven't been active in a while label Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues that haven't been active in a while
Projects
None yet
Development

No branches or pull requests

1 participant