Configure custom rubocop.yml file

[ivdma]

couldn't figure out how to set a path to a custom rubocop.yml file. Is it undocumented or is it broken? This is my config:

---
engines:
  rubocop:
    enabled: true
    config: '.custom_rubocop.yml'

[driv3r]

we have our own .rubocop.yml file within the project, but doesn't quite work.

Also just an idea, it would probably make sense to merge .rubocop.yml file from project (i.e. with custom rules, but not all of them) with .rubocop.yml file from engine for a fallback. What do you think?

[wfleming]

First, I apologize to both of you for how long it's taken us to get back to you on these issues.

@ivdma We do support an alternative rubocop config file, and your config looks correct to me (and a similar one worked for me locally). Is this still not working for you? If not, are you using the CLI or locally or running analysis on codeclimate.com? If you're using the CLI, the first thing I would try is running codeclimate engines:install: you may still have an older version of the engine from before this functionality was added.

@driv3r What about your own .rubocop.yml doesn't seem to be quite working?

Right now, we don't support importing one config file into another: normally when people want to do this, they're importing from something outside of the checked-in repo, which doesn't usually work because of how we isolate running engines. I'm hesitant to automatically merge Code Climate's default Rubocop rules into a checked-in .rubocop.yml since if we tweaked our default rules (which we do sometimes), that would change analysis results, which would be surprising & undesirable for many people who have customized their own .rubocop.yml.

We do hope to eventually support importing base config files via Rubocop's inherit_from config directive, and I think importing our default rules explicitly that way would be the way to do it, but we haven't figured out a good way to do it yet that doesn't break aspects of the limits we place on engines for security reasons.

[driv3r]

@wfleming

• I had only .rubocop.yml file with out custom cops, but it didn't work (both on CC and locally with codeclimate analyze
• I've tried adding it as config option as @ivdma but with codeclimate analyze it didn't worked as well
• I've also tried changing name of the config file, without result

so currently I don't know any way of changing this config

[wfleming]

@driv3r Would you mind sharing your .rubocop.yml & .codeclimate.yml? Feel free to email me at will@codeclimate.com if you'd rather not share those publicly. Thanks.

[dfaulken]

Running RuboCop from a custom config file isn't working for me either - everything's public so feel free to poke around - specifically this build on this PR doesn't seem to be producing any output at all.

I'm looking to do this because we have a few repositories, the one cited above included, which use our own custom RuboCop cops. Our CodeClimate builds are failing because our RuboCop config file requires the cops. (example) This works fine with our CI (Travis) because it bundles from our Gemfile and the cops are included in our gem, but CodeClimate doesn't do that.

That being said, even if it is doable to create a separate RuboCop config file and use it for CodeClimate builds, we would still need to maintain two nearly identical files, as we would simply remove the problematic require.

Provided we can get the build to work properly, is it possible to specify scripts which are run before any engines are run? In our case, the failing line is right at the top of the file, so it'd be neat if we could do something like:

before_script: "tail -n +3 .rubocop.yml > .codeclimate-rubocop.yml"
# ...
engines:
  rubocop:
    config: ".codeclimate-rubocop.yml"

This way, we could just maintain the one RuboCop config file and generate the custom file on-the-fly from that.

[RochesterinNYC]

Hi, apologies if I'm rehashing things, but I don't quite understand what the state of .rubocop.yml files are in relation to Code Climate's rubocop engine.

For Bundler, we're trying to add a .codeclimate.yml file to the repo via this PR (rubygems/bundler#4229) so that we can specify exclude_paths. This is the intended .codeclimate.yml file:

---
engines:
  duplication:
    enabled: true
    config:
      languages:
      - ruby
  fixme:
    enabled: true
  rubocop:
    enabled: true
ratings:
  paths:
  - "**.rb"
  - "bin/*"
  - "exe/*"
exclude_paths:
- bundler.gemspec
- "*.md"
- lib/bundler/ssl_certs/*.pem
- lib/bundler/vendor/**/*
- lib/bundler/templates/**/*.tt
- man/*
- spec/**/*

Adding this file has the side effect of causing the Rubocop engine on Code Climate to detect 28 new violations (https://codeclimate.com/github/bundler/bundler/pull/4229). We have a .rubocop.yml file (https://github.com/bundler/bundler/blob/master/.rubocop.yml) that uses inherit_from on a .rubocop_todo.yml file (https://github.com/bundler/bundler/blob/master/.rubocop_todo.yml) that has all these 28 "new" violations excluded.

Shouldn't the Code Climate Rubocop engine be:

• using our repo's .rubocop.yml configuration
• picking up the additional .rubocop_todo.yml via the inherit_from in .rubocop.yml
• excluding these violations in its analysis
• and then not reporting these violations?

If this should be a separate issue and not tacked onto this current issue, please let me know and I will move this over to a new issue.

[KevinBongart]

@wfleming, re: qltysh/qlty#308 (comment)

I tried a couple of things on a large codebase:

1. When .rubocop.yml inherits from .rubocop_todo.yml:
   • codeclimate analyze -e rubocop: Found 155 issues
   • rubocop: no offenses detected
2. When .rubocop.yml doesn't inherit from .rubocop_todo.yml:
   • codeclimate analyze -e rubocop: Found 3,299 issues
   • rubocop: 3834 offenses detected

There are some paths excluded for all engines in .codeclimate.yml (which explains some differences in 2.), but no specific configuration for the rubocop engine.

I'd love to pin down where these 155 issues come from: ideally, it should be 0 just like when I run rubocop manually.

1. I thought Code Climate was not letting Rubocop inherit from another Rubocop config file? It looks like it is working
2. Would it be possible to pass in Rubocop params? For instance, rubocop --display-cop-names could be very useful
3. Could this come from different Rubocop versions between my Gemfile and the CC engine?
4. What can I do to help identifying what's happening here?

[pbrisbin]

Hi @KevinBongart

I thought Code Climate was not letting Rubocop inherit from another Rubocop config file? It looks like it is working

I think we were misunderstanding inherit_from a bit and I apologize for the confusion. It's common for users to use inherit_from: ~/.rubocop.yml and that we can't support. Our analysis runs on a fresh clone and cannot access anything outside of the project root. We conflated that to mean "we don't support inherit_from", which may not be true. In fact, given your testing it seems to work provided the file from which you're inheriting is also within the project root.

Would it be possible to pass in Rubocop params? For instance, rubocop --display-cop-names could be very useful

This is not directly supported in the CLI, but depending on what you're trying to do you might have success running the engine image directly:

docker run --rm --volume $PWD:/code codeclimate/codeclimate-rubocop rubocop --display-cop-names

seems to have worked for me.

Could this come from different Rubocop versions between my Gemfile and the CC engine?

That's my best guess. It looks like the current version on DockerHub is 0.35.1

% docker run --rm codeclimate/codeclimate-rubocop rubocop --version                                  codeclimate-rubocop:master
warning: parser/current is loading parser/ruby22, which recognizes
warning: 2.2.3-compliant syntax, but you are running 2.2.2.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
0.35.1

Would it be possible for you to run that version of rubocop directly and see if it finds the same 155 issues codeclimate analyze does?

What can I do to help identifying what's happening here?

You're doing it! Your engagement in this Issue has been super helpful. It's also possible that the trick of running commands in the engine image directly is useful to figure things out.