Setting for rubocop version

[printercu]

I've seen that there are some closed issues for this. But here is one more point: new rubocop versions may have regressions (rubocop/rubocop#3673) and it gets hard to use hound. Is it still 'won't fix'?

[toppsdown]

All the new PRs just became littered with "Block has too many lines" comments in all our test files because of an update to rubocop. I can't find what version of rubocop I need to set to make our local repos obey the same rules as hound because rubocop was removed from the hound gemfile. Does it just get set to latest? Are we going to have to do this again every time they update?

[gylaz]

Hound's RuboCop version can be found here: https://github.com/houndci/linters/blob/master/Gemfile.lock#L54 (we've updated to the latest).

I totally see the frustration. We've hoped the underlying tools would be backwards compatible, and introduce new rules without enabling them. However, that has show not to be the case. A feature like locking to a particular version would help, but users aren't likely to lock to a version out of the box, so this kind of problem will keep popping up. I'd love for us to come up with a solid solution.

[printercu]

If they don't lock rubocop version on setup, they most likely would lock it once they got a batch of warnings :)

Hound gem can just provide generator, which will initialize .hound.yml with:

ruby:
  config_file: .rubocop.yml
  rubocop_version: #{local_version}

[josephbridgwaterrowe]

@gylaz it would great to see this sooner than later, something as @printercu suggests would be nice. We're in the process of looking at alternatives because of this and the "pain" that it inflicts when you change your rubocop version.

[gylaz]

To be honest, it's not likely we'll add support for this in the near future.

[aivils]

Some warning message would be very helpful!
Said, Project's and hound's rubocop versions differs. This may lead unpredictable behavior if hound.

People like me attach hound to project without deep knowledge about hound.
As a result spend day for research what is up. Only rubocop versions differs though.

[toppsdown]

Just reiterating a year later that this is still very annoying. Would love to see this enhancement added

[rmacklin]

@gylaz

Hound's RuboCop version can be found here: https://github.com/houndci/linters/blob/master/Gemfile.lock#L54 (we've updated to the latest).

This link no longer works - it seems the https://github.com/houndci/linters repo has been deleted or made private. Where can users view the version of RuboCop that hound is using?

[gylaz]

We're using 0.54.0 now. We're working on a documentation page, where we list the current versions for our linters.

[rmacklin]

Thanks, that would be helpful.

[onebree]

+1 to this enhancement. My team was trying to upgrade rubocop to the latest version (0.58.2) the other day, and adding/fixing cops as needed. But we couldn't, since Hound is locked at 0.54.0.

Setting the rubocop version in .hound.yml sounds like a great idea @printercu

[gylaz]

As an update, we are finishing up some last touches on a versioning system. Users will be able to lock to a specific version that we support via .hound.yml.

rubocop:
  config_file: .rubocop.yml
  version: 0.54.2

eslint:
  config_file: .eslintrc
  version: 4.18.2

We document the supported versions of the linters over at http://help.houndci.com/configuration (by clicking into the linter of interest).

[mmoll]

@gylaz Will there be the possibility to just put in any rubocop version in and it's getting installed or will this be a fixed version list and new versions need to get added each by hound devs?

Not directly related: Is there a possibility to add Rubocop plugins planned?

[salbertson]

@mmoll we are starting with offering specific versions to be configured. That will hopefully allow teams to stick with a version, or upgrade, and not be affected by changes to default versions used in Hound.

Not directly related: Is there a possibility to add Rubocop plugins planned?

Not sure yet. @gylaz what do you think?

[gylaz]

@mmoll Are these custom RuboCop plugins, or ones that are open-source/community supported? We're open to adding the open sources ones, as they've been (hopefully) vetted for anything malicious, but custom plugins would allow anyone to execute anything on our systems.

[mmoll]

@gylaz I'm mainly interested in https://rubygems.org/gems/rubocop-rspec and https://rubygems.org/gems/rubocop-gitlab-security

Also note that there's an effort in Rubocop itself to modularize it and split out i.e. performance and Rails cops to their own gems.

[rmacklin]

@gylaz Do you think Hound could make use of the new GitHub Actions feature so that it could run in a container? It seems like that would mitigate the security risks of executing malicious code on your servers.

[gylaz]

@mmoll We already support rubocop-rspec and we'd be happy to add rubocop-gitlab-security. As long as the gems are trusted/vetted, we have no problem supporting them.

@rmacklin That certainly is a possibility, and Actions have peaked our interest. But given our architecture and that Actions are new and it would require a large re-write in our part, it's not likely to be anytime soon.

[gylaz]

@mmoll We've added support for rubocop-gitlab-security now.

Users can now use RuboCop 0.59.2 version, by configuring it in .hound.yml:

rubocop:
  version: 0.59.2

Also, support for ESLint 5.7.0 is similarly available:

eslint:
  version: 5.7.0

http://help.houndci.com/configuration/linter-versioning

[mmoll]

@gylaz Like this: theforeman/foreman#6169 - doesn't seem to return?

[gylaz]

@mmoll Getting a Unprocessable Entity Error summary: User is blocked on our end.
Might you have blocked @houndci-bot? Does it show up in https://github.com/settings/blocked_users for you?

[mmoll]

theforeman org admins: @GregSutcliffe @ohadlevy @ehelms @tbrisker - can you see anything related? ☝️

[tbrisker]

theforeman org admins: @GregSutcliffe @ohadlevy @ehelms @tbrisker - can you see anything related? point_up

I checked, there's noting blocking on our side, the webhook is configured and doesn't show any failed deliveries recently. If needed i can check a specific delivery if you have a uuid or timestamp to look at.

[mmoll]

Hrm, I did have the hound-bot user on block in my user account, but that shouldn't have influence on the Org stuff, I presume. Anyway, I did unblock and toggle the PR, let's see, if it's getting better...

[gylaz]

@mmoll We've noticed that GitHub will throw an error if a PR is opened by the user who has blocked @houndci-bot. We now have an GitHub app (https://github.com/apps/hound), however, that can be installed on your organization instead of using the bot user.