Linthub: Static code analysis for GitHub pull requests(linthub.io)
linthub.io
Linthub: Static code analysis for GitHub pull requests
https://linthub.io/
34 comments
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.
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.
+1 for "lint errors fail the build"
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.
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.
GitLab B.V. CEO here. Totally agree that lint errors should fail the build instead of commenting. Otherwise all the people /cc't in the pull/merge request get all the hound comments in their email. And the nice thing about Rubocop https://github.com/bbatsov/rubocop is that you can disable tests easily. With GitLab we initially had: 406 files inspected, 1609 offenses detected. But after selecting only the most important checks and a day of fixing we got a green build.
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
I guess the advantage of Linthub over Phare is that it can run on pull requests made by external contributors.
Actually, it does in a certain way. Travis runs builds (tests + Phare) for all pull requests (eg. https://travis-ci.org/mirego/encore/pull_requests) so we know if pull requests made by external contributors "break the build".
This is exactly why we've develop this. To enforce code quality to pull requests and save the repository owners time.
I think he's commenting on the approach of how the system reports, not its usefulness. Have you considered bundling up the results as a second commit status[1] rather than making comments?
1: https://github.com/blog/1935-see-results-from-all-pull-reque...
1: https://github.com/blog/1935-see-results-from-all-pull-reque...
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.
There is a free open source alternative written in Python: https://github.com/justinabrahms/imhotep
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
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
So this is like Hound[1]? - I am (kinda) building something for PHP, Anorak[2] which uses something else I built.
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
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
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.
Thanks! Are you planning on charging for this? I have an error, can I email you guys?
Edit: Nevermind, I found the support form.
Edit: Nevermind, I found the support form.
Currently no plans for charging. If we'll change these plans, existing repositories will stay free. Send an email to [email protected] for the error, and we'll check it immediatly.
Error should be fixed, was an error due to redirect http to https.
Similar services:
https://houndci.com/ http://scrutinizer-ci.com/ http://landscape.io/ http://codeclimate.com/
https://houndci.com/ http://scrutinizer-ci.com/ http://landscape.io/ http://codeclimate.com/
Also: https://www.codacy.com :)
I've been working another alternative; https://github.com/jbrooksuk/anorak
Are there any opensource tools that do the same thing( like reek for ruby) ?
I would like to use something like this at work but we don't host code on github.
I would like to use something like this at work but we don't host code on github.
Try RuboCop for ruby.
Does github not have granular enough permissions to allo commenting on pull requests without granting write access to a repo?
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.
This look awesome! But there are a lot of similar services such as codeclimate.
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.