Replacing hound-ci for the JS stack

Development
1

Hello,

I am facing problems with hound-ci at the JavaScript Stack.
Currently, it works well with some minimal eslint rules, but when you want to update them, hound showing errors you never receiving locally or in our CI.

We opened an issue a while ago and we got no response:
https://github.com/houndci/hound/issues/1461

I am trying to use the new patternfly-eslint-rules (which uses prettier) with no success:
https://github.com/theforeman/foreman/pull/5566

I see a great value for the JavaScript stack, using the patternfly-eslint with a well eslint bot.

There are 3 options:

  1. Drop the eslint from hound and continue to run the eslint in Travis
  2. Drop the eslint from hound and replace it with another eslint-bot on premise (which is free for open source).
    I actually haven’t found any
  3. Drop the eslint from hound and replace it with an eslint-bot we run in our own servers. (Can use GitHub - Bernardstanislas/eslint-bot: A bot listening to github webhooks, running ESLint and sending inline comments on every commits.)

Any thoughts?
@ui_ux

1 Like
2

if hound doesn’t make our life easier (and based on the fact this is the 3rd time we are trying to properly add prettier) I’m in favor of stopping using hound for eslint, and use the travis output for failing lint instead.

2 Likes
3

Let’s just drop hound completely. I’d very much like this for obvious reasons.

  • no spam messages anymore
  • we gain full control of the linting back
  • no more linting errors sneaking in
2 Likes
4

If it helps, we dropped hound completely in Katello and it is not missed :slight_smile: Any linting is handled in jenkins

2 Likes
5

I guess I need to change my dev focus from core to katello :wink:

I’d really like to hear @tbrisker’s opinion on this, as I know he really much appreciates hound.

1 Like
6

Not having full control over the lint configuration is pain. If it’s not adding too much burden on our Jenkins I’d be for moving it there. Otherwise I’d give Travis a try.

7

PR created to drop eslint from hound-ci
https://github.com/theforeman/foreman/pull/6081

8

Sorry for the delay :slight_smile: The issue of dropping hound has come up several times before. I don’t have any specific fondness of the Hound itself, however it does provide us with something I find very valuable that currently Jenkins doesn’t know how to do: Inline comments on all linting issues.
The other alternative seems to be using jenkins which means that to understand why your linting failed you need to know how to go into jenkins and read its logs. This might not seem like a big issue for all of us experienced developers, but for new contributors it makes it much harder to understand what is wrong with their code.

9

This must be possible in Jenins as well. I think the new pipeline jobs with the blueocean interface are pretty easy to understand. In the past rubocop could generate XML files that Jenkins could understand and show comments inlined in the code. I think this would be worth investigating. And we would gain back full control over our linting.

10

If someone is willing to investigate and open a PR getting jenkins to put linting comments inline, I’d be more than happy to push the merge button and remove hound. I’m afraid my knowledge of jenkins and github api isn’t enough to accomplish this. Perhaps this could be achieved using a github app or webhook.

11

for good or bad, this was merged a while ago already… (just for JS stack)

  • errors are visible in the travis job.