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
Add linters #1107
Add linters #1107
Conversation
Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>
Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>
Signed-off-by: Mark Sagi-Kazar <mark.sagikazar@gmail.com>
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.
Should linting be a separate build workflow from running tests?
go vet ./... | ||
bin/revive ./... | ||
bin/staticcheck ./... | ||
gofmt -l -s -e . | grep .go && exit 1 |
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.
gofmt
formatting can—and has, more than once—change between versions of Go, how will we handle that when our builds straddle the versions where a change is made?
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 used the linters Peter listed in his last comment. I don't mind dropping gofmt.
Yeah, that's a good idea. |
Not really down with But what is motivating this PR? Is it a specific need, or general housekeeping? If it's general housekeeping, let's maybe wait until after a release, there's a lot of stuff in flight right now, don't you think? |
I'm not sure how much we even need golint if we're using staticcheck, I suspect there would be a lot of duplicate checks between the two. But I'm not opposed to golint. What do either of you think of using https://github.com/reviewdog/reviewdog to automate posting linter results as PR comments? I've used it for several years on work projects and find it reduces work for reviewers while simultaneously providing good feedback for contributors. |
I guess the first thing is to settle on the list of tools:
I think originally I submitted it about a year ago because of some "nit: do XY because coding style" kind of reviews. Linters can automate that and reduce turnaround time. Obviously, introducing new linters require some housekeeping.
I haven't used reviewdog before, but I'm familiar with it. I think it's a good idea, but I think GitHub Actions has a similar feature: it can decode the output (we can register decoders) and annotate specific lines. Not sure if it actually comments on the PR though. |
I gathered my strength and made the changes requested in #967 as a separate PR.
Before I go ahead and fix all those lint failures, I'd like to agree on the specific rules that we want to turn on. Right now I left everything on default mode.
Note: golint is deprecated. revive seems to be the alternative.
Fixes #967