[ci] Add errcheck to golangci-lint#7996
Conversation
|
@ajm188 AFAIK, in draft mode also the CI tests run :) |
|
huh! i have a vague memory of turning a PR back to draft mode to debug some tests and none of the CIs were running. happy to be wrong though! |
ajm188
force-pushed
the
am_errcheck
branch
6 times, most recently
from
eefb8a6 to
8dca6f7
Compare
ajm188
changed the title
errcheck to golangci-linterrcheck to golangci-lint
ajm188
requested review from
GuptaManan100,
doeg,
harshit-gangal,
rafael,
rohit-nayak-ps,
shlomi-noach and
vmg
as code owners
go/cmd/rulesctl/cmd/list.go
Outdated
There was a problem hiding this comment.
@shlomi-noach calling your particular attention to this line; I think this should be checking if m == nil (since we checked c == nil just before locking above) but wanted to confirm with you first.
There was a problem hiding this comment.
@ajm188 I believe you're right, this should be m == nil. Took me a while to understand why I have no recollection of this code, it was a contribution and I'm not too familiar with it.
There was a problem hiding this comment.
@ajm188 I believe you're right, this should be m == nil. Took me a while to understand why I have no recollection of this code, it was a contribution and I'm not too familiar with it.
deepthi
left a comment
deepthi
left a comment
There was a problem hiding this comment.
LGTM.
A couple of things:
- Review the
nolintdirectives, perhaps some of them should change to ignore the return value instead - It will be nice to update the version in https://github.com/vitessio/vitess/blob/main/misc/git/hooks/golangci-lint
go/cmd/vtctl/vtctl.go
Outdated
There was a problem hiding this comment.
nit: why not _ = ... instead of nolint?
Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
This is an often-surprising Go quirk, so I will explain a bit: An interface has two components: the concrete type, and the value. If both of these are `nil`, then the interface is equal to `nil`. If the concrete type is non-nil, even if the value for that type is nil, then the interface is non-nil. For a toy example, see: https://play.golang.org/p/0uLrBekVg_y. In this specific case, we were taking `rules.Find`, which returns `*rules.Rule` and assigning that to a variable with the type of `interface{}`. Since we have a concrete type for the interface, the `out != nil` check will never be false. The fix here is to use a second variable, which will have the concrete type, and check if the pointer is nil, which is what we actually wanted here. Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
…lint directives Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
Signed-off-by: Andrew Mason <amason@slack-corp.com>
|
Still need to update the version we download in the hook (if the binary doesn't exist locally). vitess/misc/git/hooks/golangci-lint Line 28 in 8b7a4cb Also, do we need to announce/warn people in #developers that they will need to upgrade their installed version of the linter? |
Signed-off-by: Andrew Mason <amason@slack-corp.com>
|
yeah, i was planning to post in #developers after i merged! |
6 participants
Description
This PR enables the
errchecklinter as part of thegolangci-lintlinter suite, and then sets up a bunch of configs to allow us to progressively enable this linter on more and more parts of the codebase.To make this work, I needed to bump the version of
golangci-linttov1.39.0, since earlier versions were not correctly working with theerrcheck_excludes.txtfile. I can't go all the way to the latest version (v1.40.1) because that starts to complain about stuff in the fuzz tests, and I didn't want to touch those in this change haha.After I got the config into a working state, I then moved through and fixed up a bunch of the now-complaining
errcheckfailures. I stuck to packages that had relatively few failures, and to errcheck violations that I thought would be pretty uncontroversial to fix. The rest of the packages I've left as ignored in our.golangci.ymlconfig, and as we gradually fix those instances we can remove those entries from the config.Related Issue(s)
Closes #8222
Checklist
Deployment Notes