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
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:
Our CI pipeline is configured to use our_gem version X1.
We release our_gem version X2, but don't install it on the CI pipeline.
Teams are notified that the new version is available and they are given time to review and request changes.
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.
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).
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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!
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:
There's nothing that tells rubocop which version of
our_gem
to load. Up until rubocop0.85.0, rubocop picked the latest version of
our_gem
. 0.85.0 was enhanced to use the version thatbundler
resolves. This is a great improvement, but it only helps whenour_gem
is listed in the Gemfiles. We typically don't includeour_gem
, orrubocop
, 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 controlour_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 ofour_gem
manages to get installed on the CI server. Once it's there, problems quickly start. Consider this scenario:our_gem
version X1.our_gem
version X2, but don't install it on the CI pipeline.our_gem
in their Gemfile, runs a build on the CI pipeline and installsour_gem
X2 on the CI server for everyone else.rubocop
runs for someone on the CI server, it uses the configuration from X2 (because rubocop always loads the configuration from the latest version ofour_gem
).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:
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.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 ofour_gem
to select.The text was updated successfully, but these errors were encountered: