Change:
func (r *ServiceRegistry) ExportService(ctx api.Context, name string, options unversioned.ExportOptions) (*api.Service, error) { r.mu.Lock() <del> defer r.mu.Lock() </del> <ins> defer r.mu.Unlock() </ins> return r.Service, r.Err }

Discussion:
Hi, I ran on Kubernetes at commit , filtered out benign issues and false positives and assembled the following report, grouped by category and sorted by severity in descending order. I hope this report is useful to you. The following line of code defers instead of : The following lines of code open files or connections and defer before checking the returned error. This will lead to panics in case of an error. In the following instances, values are being assigned to struct fields in methods with value receivers, without ever reading the fields again. This either suggests unnecessary assignments, or receivers that should be pointers instead. Per the testing.T documentation, T.FailNow, and by extension Fatal, Fatalf and so on, must be called on the same goroutine as the test, not in other goroutines. That invariant is violated in the following places: The following instances use Printf even though they don't need format strings. In some cases, the inputs are user provided, which can lead to incorrect output: The following condition compares with itself. That's either pointless, or a possible copy & paste eror: These values of are never evaluated: The following loops always loop at most once, indicating bugs or unnecessary control flow constructs: The following arguments are being overwritten before their first use. Judging from context, this is either because of missing pointer dereferences, or because of useless arguments: The same error class as assigned but not read errors, but indicating left over useless code, not missing error checking: All of these slices are never used. Most are lists of things that are discarded, some are values that are subsequently overwritten unconditionally.
Opened for the aws codesmell issue. Could we get staticcheck into e2e I wonder?
/assign Is this still an issue?
/unassign
You could run on a recent commit of Kubernetes to confirm whether the reported issues have already been resolved.
someone pay this guy, that was incredible.
We should scrub this and run it as a verify script.
cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity.

Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
/lifecycle frozen /remove-lifecycle stale
/remove-lifecycle rotten
/cc
I started opening a bunch of PRs for this:
We do run staticcheck now and we've had various PRs regarding fixing code bugs and removing them from the failures list, but there are still many failing packages ... I think fixing the failures should be a distinct bug from adding staticcheck to CI (done in ) and is mostly what has been discussed here after the initial comment. I've filed a "good first" issue with more & updated detail for newcomers to help fix these. Thanks everyone who's helped so far and for reporting. /remove-sig contributor-experience /close
Closing this issue. <detailsIn response to : We do run staticcheck now and we've had various PRs regarding fixing code bugs and removing them from the failures list, but there are still many failing packages ... I've filed a "good first" issue with more & updated detail for newcomers to help fix these. /remove-sig contributor-experience /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details