The corresponding "pull-kubernetes-verify-lint" job was already removed
earlier. Manual strict checking was still possible, but doesn't really make
sense for the same reasons why the job was removed (e.g. the decisions which
checks should be "strict" were too arbitrary).
The explanations for "hints" no longer end with "In general please prefer to
fix the error, ..." because that was misleading and only really applied to the
checks for existing code. For those checks we prefer to fix errors instead of
suppressing them, but not for hints.
The context is used for cancellation and to support contextual logging.
In most cases, alternative *WithContext APIs get added, except for
NewIntegerResourceVersionMutationCache where code searches indicate that the
API is not used downstream.
An API break around SharedInformer couldn't be avoided because the
alternative (keeping the interface unchanged and adding a second one with
the new method) would have been worse. controller-runtime needs to be updated
because it implements that interface in a test package. Downstream consumers of
controller-runtime will work unless they use those test package.
Converting Kubernetes to use the other new alternatives will follow. In the
meantime, usage of the new alternatives cannot be enforced via logcheck
yet (see https://github.com/kubernetes/kubernetes/issues/126379 for the
process).
Passing context through and checking it for cancellation is tricky for event
handlers. A better approach is to map the context cancellation to the normal
removal of an event handler via a helper goroutine. Thanks to the new
HandleErrorWithLogr and HandleCrashWithLogr, remembering the logger is
sufficient for handling problems at runtime.
This is a workaround for a false positive in the staticcheck linter,
which has not been addressed yet.
See https://github.com/dominikh/go-tools/issues/1294.
Once this is fixed in staticcheck, we can just remove the exclude rule
from the golangci config.
Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
In contrast to the original HandleError and HandleCrash, the new
HandleErrorWithContext and HandleCrashWithContext functions properly do contextual
logging, so if a problem occurs while e.g. dealing with a certain request and
WithValues was used for that request, then the error log entry will also
contain information about it.
The output changes from unstructured to structured, which might be a breaking
change for users who grep for panics. Care was taken to format panics
as similar as possible to the original output.
For errors, a message string gets added. There was none before, which made it
impossible to find all error output coming from HandleError.
Keeping HandleError and HandleCrash around without deprecating while changing
the signature of callbacks is a compromise between not breaking existing code
and not adding too many special cases that need to be supported. There is some
code which uses PanicHandlers or ErrorHandlers, but less than code that uses
the Handle* calls.
In Kubernetes, we want to replace the calls. logcheck warns about them in code
which is supposed to be contextual. The steps towards that are:
- add TODO remarks as reminder (this commit)
- locally remove " TODO(pohly): " to enable the check with `//logcheck:context`,
merge fixes for linter warnings
- once there are none, remove the TODO to enable the check permanently
Wrapping errors may or may not be the right thing to do (see
https://go.dev/blog/go1.13-errors#whether-to-wrap and the discussion in
https://github.com/kubernetes/kubernetes/issues/123234). But developers should
at least think about it, so let's emit linter hints for it: the golangci-lint
config by default enables it for go-errorlint, just not the linter itself, so
we just need to add it for the "hints" config.
Direct error comparisons and assertions also get checked. Those are typically
something that should be replaced by errors.Is and errors.As, but as the
existing code often doesn't do that, let's also treat those as just hints.
* cmd/kube-proxy support contextual logging
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* use ktesting.NewTestContext(t) in unit test
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* use ktesting.NewTestContext(t) in unit test
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* remove unnecessary blank line & add cmd/kube-proxy to contextual section in logcheck.conf
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* add more contextual logging
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* new lint yaml
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
---------
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
`BeTrue` without explanation in `Should` just prints "false is not true", which
isn't a useful failure message. Even with an explanation that message is still
printed, which is just noise. The new BeTrue/FalseBecause avoid that by
requiring that an explanation is provided and using that instead of "false is
not true".
In Kubernetes, we can enforce the usage of those better alternatives or the
if+Fail combination via forbidigo. Because we have existing code which still
needs to be updated, this can only be a hint for now.
Some examples found with this:
ERROR: test/e2e/apimachinery/protocol.go:75:20: use of `o.BeTrue` forbidden because "it does not produce a good failure message, use BeTrueBecause with an explicit printf-style failure message instead or plain Go: if ... { ginkgo.Fail(...) }" (forbidigo)
ERROR: o.Expect(ok).To(o.BeTrue())
ERROR: ^
ERROR: test/e2e_node/unknown_pods_test.go:163:52: use of `gomega.BeTrue` forbidden because "it does not produce a good failure message, use BeTrueBecause with an explicit printf-style failure message instead or plain Go: if ... { ginkgo.Fail(...) }" (forbidigo)
ERROR: }, f.Timeouts.PodStart, f.Timeouts.Poll).Should(gomega.BeTrue())
ERROR: ^
The solution might also be to write a custom matcher, but that is a bit hard to
explain in the forbidigo message.
39df946c06 was meant to enable stricter comment checking only for cmd/kubeadm
because the maintainers of that want that. However, the exclude rule didn't
capture all possible error texts and therefore some checks were enabled across
the entire code base.
The extended pattern is now based on the golangci-lint source code.
Also, the hint config didn't suppress any of these checks.
Some code owners might want this for specific packages, like cmd/kubeadm.
This cannot be enabled for everything because:
- a lot of existing code doesn't pass (-> can't be in base config)
- a lot of packages don't need it (-> shouldn't even be a hint)
The voting in https://github.com/kubernetes/kubernetes/issues/117288 led to
one check that got rejected ("ifElseChain: rewrite if-else to switch
statement") and several that are "nice to know".
golangci-lint's support for issue "severity" is too limited to identify "nice
to know" issues in the output (filtering is only by linter without considering
the issue text; not part of text output). Therefore a third configuration gets
added which emits all issues (must fix and nits). The intention is to use
the "strict" configuration in pull-kubernetes-verify and the "hints"
configuration in a new non-blocking pull-kubernetes-linter-hints.
That way, "must fix" issues will block merging while issues that may be useful
will show up in a failed optional job. However, that job then also contains
"must fix" issues, partly because filtering out those would make the
configuration a lot larger and is likely to be unreliably (all "must fix"
issues would need to be identified and listed), partly because it may be useful
to have all issues in one place.
The previous approach of manually keeping two configs in sync with special
comments didn't scale to three configs. Now a single golangci.yaml.in with
text/template constructs contains the source for all three configs. A new
simple CLI frontend for text/template (cmd/gotemplate) is used by
hack/update-golangci-lint-config.sh to generate the three flavors.
