* 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>
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)
This particualar warning didn't make it into
https://github.com/kubernetes/kubernetes/issues/117288. Discussion on Slack
concluded that "it's hard to have a universal policy for all functions marked
deprecated" and thus this can only be a hint which must be considered on a
case-by-case basis.
For example, APIs like sets.String are very unlikely to ever go away, therefore
it is entirely up to developers whether they switch to sets.Set even though
sets.String is marked as deprecated.
Ideally, the deprecation message should explain this. It doesn't for sets ("use
generic Set instead"), so a better message in that case would have been
"consider using generic Set instead".
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.
Client-side extract calls depend on `managedFields`, which might not be
available. Therefore they should not be used in production code.
They are okay in test files (because the API has to be tested), in the
generated code (because the various type specific APIs still need to be
provided) and in unstructured.go (same reason).
For example, this is a false positive that currently exists in the code base:
test/e2e_node/dra_test.go:129:4: ginkgo-linter: use a function call in Consistently. This actually checks nothing, because Consistently receives the function returned value, instead of function itself, and this value is never changed; consider using `gomega.Consistently(ctx, e2epod.Get).WithArguments(f.ClientSet, pod).WithTimeout(podInPendingStateTimeout).Should(e2epod.BeInPhase(v1.PodPending),
"Pod should be in Pending state as resource preparation time outed")` instead (ginkgolinter)
gomega.Consistently(ctx, e2epod.Get(f.ClientSet, pod)).WithTimeout(podInPendingStateTimeout).Should(e2epod.BeInPhase(v1.PodPending),
^
It's a false positive because e2epod.Get returns the function that Consistently
is meant to call.
This could be worked around by assigning e2epod.Get(f.ClientSet, pod) to a
variable and then use that variable, but that is less readable.
In strict mode, stylecheck complains about Convert_* and SetDefaults_*
functions in Kubernetes because they use underscores. We want to allow that to
make the functions more readable.
https://github.com/kubernetes/kubernetes/pull/109728 added a
golangci-strict.yaml where gingkolinter and stylecheck (some recent additions
to golangci.yaml) were missing.
To prevent such mistakes in the future, lines that are intentionally different
get annotated with a comment about golangci-strict.yaml or golangci.yaml.
Then a suitable diff command in the new verify-golangci-lint-config.sh checks
that only such lines, comments and blank lines are different.
It is useful to check new code with a stricter configuration because we want it
to be of higher quality. Code reviews also become easier when reviewers don't
need to point out inefficient code manually.
What exactly should be enabled is up for debate. The current config uses the
golangci-lint defaults plus everything that is enabled explicitly by the normal
golangci.yaml, just to be on the safe side.
