Live data from Hacker News

Linthub: Static code analysis for GitHub pull requests

linthub.io

11–20 of 35 posts

Re: Linthub: Static code analysis for GitHub pull requests

#11
post #10
post #9

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 guess the advantage of Linthub over Phare is that it can run on pull requests made by external contributors.

This is exactly why we've develop this. To enforce code quality to pull requests and save the repository owners time.

Re: Linthub: Static code analysis for GitHub pull requests

#12
post #10
post #9

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 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".

Re: Linthub: Static code analysis for GitHub pull requests

#13
post #12
post #10

Earlier quoted context omitted.

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".

Yes, true, but only if it breaks. This enforces common code quality issues, so it will run side-to-side with travis.

Re: Linthub: Static code analysis for GitHub pull requests

#14
post #13
post #12

Earlier quoted context omitted.

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".

Yes, true, but only if it breaks. This enforces common code quality issues, so it will run side-to-side with travis.

In all my projects (and the projects I contribute to), style issues are a build-breaking defect.

In Python this usually means running flake8 as a Travis job.

Re: Linthub: Static code analysis for GitHub pull requests

#16

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.

Re: Linthub: Static code analysis for GitHub pull requests

#17
post #3
post #2

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.

Thanks! Will check and handle this.

The release with commenting on pull requests is active now. Linthubot will comment on the pull request itself instead of the commit.

Re: Linthub: Static code analysis for GitHub pull requests

#19
post #11
post #10

Earlier quoted context omitted.

I guess the advantage of Linthub over Phare is that it can run on pull requests made by external contributors.

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...

Post reply on HN