-
-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
golangci-lint configuration file #895
Conversation
Its possible (see golangci/golangci-lint#825) that this is because |
golangci-lint can run all the currently enabled linters, and as far as I can tell, does it in under 5 seconds as opposed to over 180 seconds (compare `time make cilint` and `time make lint`). Some of the linters that are listed in the "enabled" section but commented out looked like a good idea to me, and fairly low hanging fruit to fix, but they are not passing at the moment. All the linters covered in the current Makefile are run. TODO: - replace lint target in Makefile with golangci-lint - remove .github/workflow/errcheck.yml
The inline annotations are nice (the existing integration likely has them, too, that's not an advantage). Turns out it was just a |
Times for runs can be seen below. golangci-lint was 1m, imports check 51 sec, the others are 2m+. A small win. |
This will be great on the CI system. For local installs we'll need to ensure that the user has it installed. What do you think of changing That way we don't need two lint commands. |
And this change to the original
|
Yes, running the tool against multiple inputs simultaneously helps the current stuff a lot, its basically the optimization that golangci-lint does. The current The build tool situation with go modules seems a bit obscure ATM, from golang/go#25922 I've found and tried https://github.com/go-modules-by-example/index/blob/master/010_tools/README.md, but I still needed a setup style target:
Other than an explicit setup target, I don't see a way of ensuring dev-time tools are available. Adding a tools.go to the above seems to be a way to ensure exact versions of the tools are installed, which could be a big deal for a long-running large project that needs stable builds over years, but not so much here. |
@@ -86,6 +86,9 @@ install: | |||
@echo "${APP} installed into ${INSTALLPATH}" | |||
|
|||
## lint: runs a number of code quality checks against the source code | |||
cilint: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have mentioned, I called this cilint
just so I could leave the original lint
target in. Its a poor name, given that ci doesn't use it, it just uses the action. Oops.
I think the cilint
target should be renamed lint
, and the (current) lint
target deleted.
That’s an excellent point about the current one, I’d forgotten they’re not go standard. Let’s go straight with golintci. |
Btw, I don't use vscode, but it has golangci-lint integrations: https://golangci-lint.run/usage/integrations/, might be useful (I'm not sure if the standalone tools also do that). |
ok, give me a chance to tidy this up a bit, I'll add at least a couple comments so people know how to do the setup. Actually, WDYT, |
Go with the simplest to implement option at this stage. I suspect 99% of contributors don’t use the |
steps: | ||
- uses: actions/checkout@v2 | ||
- name: golangci-lint | ||
uses: golangci/golangci-lint-action@v0.2.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JFYI we've launched v1 with support of caching and without slow docker image pulling, it works much faster
golangci-lint can run all the currently enabled linters, and as far as I
can tell, does it in under 5 seconds as opposed to over 180 seconds
(compare
time make cilint
andtime make lint
).Some of the linters that are listed in the "enabled" section but
commented out looked like a good idea to me, and fairly low hanging
fruit to fix, but they are not passing at the moment.
All the linters covered in the current Makefile are run.
TODO:
Just a suggestion. It might be much faster, and yet do the same thing, win-win. I did some fixing of things
gocritic
didn't like (its a big fan of switch statements over if/if else/if else/else series), but then stopped and disabled it. Some of the sec warnings seem not applicable to wtf given that it does shell out to user-defined commands at times, so enabling gosec would involve whitelisting some of the warnings. Etc.On the down side, since this is passing, I won't see the line-annotation feature that is supposed to be enabled... maybe I should enable a couple of the failing linters temporarily in the PR, so that feature is visible?