What are the best tools for code quality checks to use within Github?
Hi team: Does anyone know an open source tool that checks PR before merge for code quality? I'm looking for something similar to code climate or codacy. I don't want to hook a Jenkins job that makes the usability of Pylint harder. -- Ahmed
I use pre-commit via tox: https://github.com/PyCQA/modernize/blob/master/setup.cfg#L94-L97
Hey, On Fri, Sep 18, 2020 at 05:55:29PM -0400, Ahmed Hassan wrote:
Does anyone know an open source tool that checks PR before merge for code quality? I'm looking for something similar to code climate or codacy. I don't want to hook a Jenkins job that makes the usability of Pylint harder.
What do you mean with "makes the usability of Pylint harder" exactly? The usual way is to run pylint via e.g. GitHub Actions or Travis CI, usually also using something like tox or pre-commit. https://docs.github.com/en/actions/guides/building-and-testing-python#runnin... https://tox.readthedocs.io/ Florian -- me@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
Thanks Thomas, I will try that. That's my next option. @Florian: Pylint itself is perfectly fine. However, I want to see all the pylint issues to be shown within the PR instead of another console. Also, I don't want to run pylint on the whole file, I want to run it only on the code that was added. On Mon, Sep 21, 2020 at 6:47 AM Florian Bruhin <me@the-compiler.org> wrote:
Hey,
On Fri, Sep 18, 2020 at 05:55:29PM -0400, Ahmed Hassan wrote:
Does anyone know an open source tool that checks PR before merge for code quality? I'm looking for something similar to code climate or codacy. I don't want to hook a Jenkins job that makes the usability of Pylint harder.
What do you mean with "makes the usability of Pylint harder" exactly?
The usual way is to run pylint via e.g. GitHub Actions or Travis CI, usually also using something like tox or pre-commit.
https://docs.github.com/en/actions/guides/building-and-testing-python#runnin... https://tox.readthedocs.io/
Florian
-- me@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
-- Ahmed Hassan Engineering Ahassan@RapidSOS.com This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
Hey again, On Mon, Sep 21, 2020 at 07:15:09AM -0400, Ahmed Hassan wrote:
However, I want to see all the pylint issues to be shown within the PR instead of another console.
You can do that by registering a "problem matcher" file with GitHub Actions, which defines a regex to parse the console output. Here's what I came up with: https://github.com/PyCQA/pylint/pull/2758#issuecomment-696059847 Example of it in use (though with a false-positive): https://github.com/qutebrowser/qutebrowser/pull/5317/files#diff-aae12401377b... Some more docs: https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md
Also, I don't want to run pylint on the whole file, I want to run it only on the code that was added.
I don't think that's possible from pylint's side. Florian -- me@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
Hi, On 21.09.20 13:15, Ahmed Hassan wrote:
@Florian: Pylint itself is perfectly fine. However, I want to see all the pylint issues to be shown within the PR instead of another console. Also, I don't want to run pylint on the whole file, I want to run it only on the code that was added.
There are SaaS tools that will run pylint and other tools on all your commits and will show the diff of issues for pull requests. Almost all of them integrate with Github. I happen to work on such a tool :-) You can find it at https://codedb.app. It is not 100% ready yet and I will re-brand it before I do a full public release. Most of the competitors (Code climate, Codacy, Codeflow, deepsource, codefactor) do very similar things but usually try to cover many different programming languages and their linters, while my product is focused on Python code only. Cheers, Martin PS: I hope it's ok to mention people to my tool, I tried to be fair and also included the competitors.
@Florian: I think I will endup building my own opensource tool. @Martin, I'm not looking for commercial solutions. Most of the SaaS tools I have seen are half-assed. I can just hook up pylint with the CI server, and pre-commit before merging. Thanks to everyone who responded to me. On Mon, Sep 21, 2020 at 7:59 AM Martin Vielsmaier <martin@vielsmaier.net> wrote:
Hi,
On 21.09.20 13:15, Ahmed Hassan wrote:
@Florian: Pylint itself is perfectly fine. However, I want to see all the pylint issues to be shown within the PR instead of another console. Also, I don't want to run pylint on the whole file, I want to run it only on the code that was added.
There are SaaS tools that will run pylint and other tools on all your commits and will show the diff of issues for pull requests. Almost all of them integrate with Github.
I happen to work on such a tool :-) You can find it at https://codedb.app. It is not 100% ready yet and I will re-brand it before I do a full public release. Most of the competitors (Code climate, Codacy, Codeflow, deepsource, codefactor) do very similar things but usually try to cover many different programming languages and their linters, while my product is focused on Python code only.
Cheers, Martin
PS: I hope it's ok to mention people to my tool, I tried to be fair and also included the competitors.
-- Ahmed Hassan Engineering Ahassan@RapidSOS.com This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
On Mon, Sep 21, 2020 at 07:15:09AM -0400, Ahmed Hassan wrote:
@Florian: Pylint itself is perfectly fine. However, I want to see all the pylint issues to be shown within the PR instead of another console. Also, I don't want to run pylint on the whole file, I want to run it only on the code that was added.
diff-cover is a nice tool that can show missing code coverage or new lint issues for a git branch. Basically it computes the diff and then filters reports produced by other tools (coverage, pylint) to show only those that affect changed lines. Check it out: https://github.com/Bachmann1234/diff_cover#quality-coverage Marius Gedminas -- Favorite MS-DOS error message: "Drive C: not ready, close door."
participants (5)
-
Ahmed Hassan -
Florian Bruhin -
Marius Gedminas -
Martin Vielsmaier -
Thomas Grainger