Feat: Use version of rubocop specified in gemfile

[kjg]

Would it be possible for codeclimate to use the same version of rubocop (and any rubocop extensions like ruboco-rspec) as specified in the projects Gemfile.lock (if it shows up there) so that the errors are the same in codeclimate as they would be locally?

[wyefei]

Are you guys working on this?

[rwadstein]

We have recently signed up for CodeClimate and are having the same issue. We recently were using HoundCi and with the switch to CodeClimate we are being forced to downgrade the version of rubocop in order to have the same results between local and CC. Also all of our configurations would have to go back to the old namespace.

[maxjacobson]

@rwadstein Hi there. Depending which version of RuboCop you're using outside of Code Climate, we may already support it via engine channels. We currently offer these channels:

• rubocop-0-42
• rubocop-0-46
• rubocop-0-48
• rubocop-0-49

And we're planning to add a rubocop-0-50 soon (see tracking issue)

Long-term we may do something more automatic than this, but for the time being, please pick the channel that you prefer and feel free to let us know when we're missing support for things that you need.

[rwadstein]

@maxjacobson Thank you for the info. Support had told me that last week and we addressed the issue on our side.. I should have come back to this issue in order to update it.

[maxjacobson]

Oh, glad to hear it 👍.

[coding-bunny]

So is this idea ever going to happen?

[maxjacobson]

Hi @coding-bunny. Thanks for checking in. I'm not sure about ever, which is a long time, but for the time being, channels remain our solution to this problem.

[andi-dev]

Unfortunately It seems the rubocop channels do not get updated frequently - by now version 0.76 is released. And is there any supported way to get rubocop extensions to work?

Thanks in advance.

[coding-bunny]

I've given up on running RuboCop through CodeClimate and made it part of our CI instead of the CodeClimate plugin.

[klyonrad]

Just saying this for your priorization: This is the number one reason why I would never ever take the paid plain. If my team were bigger than 4 I would build something on my own for Pull Request linting with pronto.

[klyonrad]

Also rubocop extensions should not be forgotten, mainly rubocop-rails.

[williamweckl]

Any updates?

[severin]

Any updates?

[fonji]

Any updates?

[pboling]

I am trying to setup a new open source gem with CI on Gitlab. I am new to Gitlab, but my goal was to first get it working with the "default" config, without customizing anything on the Gitlab side. This doesn't seem to be possible, and the reason is 💯 this issue / CodeClimate. I am getting this error if I load any RuboCop extension gems. Here is a snippet of the .rubocop.yml:

inherit_gem:
  rubocop-lts: rubocop-lts.yml

require:
  - 'rubocop-md'
  - 'rubocop-minitest'
  - 'rubocop-packaging'
  - 'rubocop-performance'
  - 'rubocop-rake'
  - 'rubocop-thread_safety'

Many of these are "core" RuboCop plugins that are generally recommended for use in any Ruby project, so I would expect to be able to use them. Must I use a custom config file in order to accomplish this?

It appears that the root cause is the code quality job doesn't run bundle install, so it doesn't have access to any of my custom RuboCop dependencies (which I have added to the Gemfile).

Job run ref.

Of note, current RuboCop paradigm is to extract rule sets into discrete gems per domain, and then the core gem will detect if these discrete gems should be recommended to the user based on gem presence. This means that over time the rubocop gem itself will be increasingly reduced, while the extension libraries will continue to grow, and without the ability to use these extensions the codeclimate solution (a "no bundler" solution) will be increasingly outmoded.

This is from latest RuboCop's default config:

  # Determines if a notification for extension libraries should be shown when
  # rubocop is run. Keys are the name of the extension, and values are an array
  # of gems in the Gemfile that the extension is suggested for, if not already
  # included.
  SuggestExtensions:
    rubocop-rails: [rails]
    rubocop-rspec: [rspec, rspec-rails]
    rubocop-minitest: [minitest]
    rubocop-sequel: [sequel]
    rubocop-rake: [rake]
    rubocop-graphql: [graphql]

CodeClimate implementation of RuboCop is entirely at odds with current reality.

Please fix?

FWIW - In the past I have always turned off CodeClimate's RuboCop feature for any projects that used CodeClimate because... it is terrible for this exact same reason. If you aren't aware of this - maybe you haven't used it? Do More Dog Food. I can't turn off the feature when it is run via Gitlab without doing extra config, which is what I was trying to avoid.