Instead of using a service like this one (or Hound) that comments directly on pull requests, we chose to integrate the same tools in our build process with Phare (https://github.com/mirego/phare), a command-line tool we built which runs Rubocop, JSHint, JSCS, etc. and exits with a global status.
If the code has coding style violations, the build breaks. Exactly like it would if we pushed a failing test.
Personally, I’m not a fan of the noise generated by comments about coding style on pull requests.
There's an obvious trade-off here, though. For example, why stop at basic lint-style checks? You could make a static analyzer part of the build process and fail the build when a defect is detected. The trade-off is the same as with growing a test suite that always runs: Over time, your build times increase, and that makes development tedious.
There's a balance to be found between core checks that run at build time, and additional, more extensive checks, which run automatically and asynchronously (!) once a developer believes their changes to be good enough. Both things have their place in a proper software development flow.
If you also add "and any coding style things you care about, you have to make the linter check for", then you don't have to waste any time on that stuff in the pull request.
Same for me. I used Hound for a while but it was annoying to see all this comments. So I just added Rubocop check inside `rake test` so build is broken if you have code style issues
This looks pretty awesome and will just get better as more languages get supported. But, it comments on commits, not on the diff in the PR. I think commeting on the diff looks nicer (you see code snippet with the comment) and in my opinion it's also easyer to find all the comments that way. Instead of clicking the commit hash on the commen each time.
It seems comparable, though we are supporting different languages. Plans are to support a lot more languages, and support private repos also. (Actually they are already supported, but linthubot needs to have read only access to the repository). All feedback is welcome.
Yeah, true. We've tightened the scope, read/write is not necessary any longer. Only for private repo's, the linthubot user needs to be added to the repo with read access.
remi|11 years ago
If the code has coding style violations, the build breaks. Exactly like it would if we pushed a failing test.
Personally, I’m not a fan of the noise generated by comments about coding style on pull requests.
nhaehnle|11 years ago
There's a balance to be found between core checks that run at build time, and additional, more extensive checks, which run automatically and asynchronously (!) once a developer believes their changes to be good enough. Both things have their place in a proper software development flow.
cjbest|11 years ago
If you also add "and any coding style things you care about, you have to make the linter check for", then you don't have to waste any time on that stuff in the pull request.
randx|11 years ago
hk__2|11 years ago
zidar|11 years ago
nl5874|11 years ago
nl5887|11 years ago
konradko|11 years ago
It runs on the commit diff with a specified linting tool (used it with pep8 and jshint), it is also fairly easy to add new linters.
Here's a fork that works nicely with Travis: https://github.com/glowdigitalmedia/imhotep
jbrooksuk|11 years ago
What's your plan on this? I'd like to use it for our private repositories.
Edit: My web hooks are returning errors. I'll submit some feedback.
[1] https://houndci.com
[2] https://github.com/jbrooksuk/anorak
nl5874|11 years ago
untitaker_|11 years ago
https://houndci.com/ http://scrutinizer-ci.com/ http://landscape.io/ http://codeclimate.com/
jaimefjorge|11 years ago
jbrooksuk|11 years ago
joncp|11 years ago
dominotw|11 years ago
I would like to use something like this at work but we don't host code on github.
russianbandit|11 years ago
lsaferite|11 years ago
nl5887|11 years ago
jchomali|11 years ago