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

--parallel disables --force-default-config #7881

Closed
defsprite opened this issue Apr 16, 2020 · 2 comments
Closed

--parallel disables --force-default-config #7881

defsprite opened this issue Apr 16, 2020 · 2 comments

Comments

@defsprite
Copy link

defsprite commented Apr 16, 2020

It seems like the --parallel-switch breaks using --force-default-config when inherited_from uses a broken / unavailable URL.

This is probably related to #7790


Expected behavior

In a project with a local .rubocop.yml, running

rubocop --parallel --force-default-config .

should ignore the config given in .rubocop.yml

Actual behavior

rubocop --parallel --force-default-config .

still uses the local .rubocop.yml. The same applies to using --config /dev/null instead of --force-default-config

Steps to reproduce the problem

  • Create a project with a local .rubocop.yml config
  • Make sure the config uses inherit_from with an unresolvable URL.
  • Compare running rubocop with --force-default-config and --force-default-config --parallel

Alternatively use the example project at https://github.com/defsprite/rubocop-bug

RuboCop version

🌀 rubocop -V
0.82.0 (using Parser 2.7.0.2, running on ruby 2.6.5 x86_64-darwin19)
@jonas054
Copy link
Collaborator

This one I have not been able to reproduce. I could reproduce #7790 without problem, and I will provide a fix for it.

@defsprite
Copy link
Author

Did a bit more sleuthing on this: It only happens when the local config contains inherit_from with a broken/unavailable URL.

Added an example project here as well: https://github.com/defsprite/rubocop-bug

jonas054 added a commit to jonas054/rubocop that referenced this issue Apr 19, 2020
This fixes another problem that's similar to the one reported in rubocop#7790. The
problem is still that configuration is read and cached when we validate options
vs configuration. By acting on all options first, we make sure that the first
time we read configuration, it's done according to the given options.
Specifically, it's the --force-default-config option that's now being
respected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants