Without these select statements, this test runs until the package-global
timeout and causes a panic. This change makes the test fail faster and
more legibly.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
This commit teaches the shell completion logic how to handle the
<type>/<name> form for resource specification.
It also teaches the 'exec' command how to complete its '--container/-c'
flag using container names.
Also, for commands that work on pods, kubectl will now also suggest
completion choices of the form <type>/<name> for resource types that
contain pods (see below for more details).
The following commands can now have completion of the <type>/<name>
form. Commands that accept any resource type:
annotate
apply edit-last-applied
apply view-last-applied
delete
describe
edit
get
label
patch
Commands that accept a subset of resource types:
autoscale
expose
rollout history
rollout pause
rollout restart
rollout resume
rollout status
rollout undo
scale
taint
Commands that apply to resource types that contain pods:
attach
exec
logs
port-foward
For these last four commands, the possible resource types are now
included in the completion choices. For example:
kubectl exec d<TAB>
will suggest
daemonsets/ deployments/
Signed-off-by: Marc Khouzam <marc.khouzam@montreal.ca>
Running logcheck as part of golangci-lint has several advantages:
- faster checking because finding files and parsing is shared
with other linters
- gets rid of the complex and buggy
hack/verify-structured-logging.sh (https://github.com/kubernetes/kubernetes/issues/106746)
- support for // nolint:logcheck
- works with Go 1.18
Some of these changes are cosmetic (repeatedly calling klog.V instead of
reusing the result), others address real issues:
- Logging a message only above a certain verbosity threshold without
recording that verbosity level (if klog.V().Enabled() { klog.Info... }):
this matters when using a logging backend which records the verbosity
level.
- Passing a format string with parameters to a logging function that
doesn't do string formatting.
All of these locations where found by the enhanced logcheck tool from
https://github.com/kubernetes/klog/pull/297.
In some cases it reports false positives, but those can be suppressed with
source code comments.
If a staging repo has .gitattributes files containing the `export-subst`
attribute ([example](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/.gitattributes)), then git expands the specified placeholders
when git archive is used.
When a published repo is downloaded from GitHub, GitHub does a
"git archive" under the hood. This means that the placeholders get
replaced by their relevant values. This type of "git archive"
application sometimes leads to undesired values. See the example below.
- In client-go, [line 59 in `pkg/version/base.go`](b6c06a95d7/staging/src/k8s.io/client-go/pkg/version/base.go (L59))
is expanded on a git archive. This line is needed as a fallback to
inject k8s version info for client-go when this info is not provided
via ldflags during builds.
- However, when k/client-go is vendored, the line gets expanded to _the
commit of the project vendoring client-go_ -- which is not helpful at
all! This also means that the vendored client-go will now contain
different (expanded) commit shas for different projects.
- To ensure reproducibility of source, this commit helps remove
the .gitattributes files before publishing the staging repos.
Additionally, when client-go is used as a library, we don't care about
the line being expanded to inject version info so it is also safe to
remove these files.
When tests attempt to validate behavior in the case that a client asks
for a resource version that is "too large" for the underlying storage,
the previous implementation would simply add 1 to the latest revision
seen. This is only appropriate for storage backends that
a) provide a continuous monotonic logical clock
b) have no other events occurring while the test runs
For instance, when using a singe etcd backend as a shared fixture for
these tests, adding 1 to a previously-seen revision is not suffcient to
ensure that the resulting revision is "too large". By instead using the
largest possible integer value, we can be certain of this.
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
