A full string comparison might fail when the underlying libraries change how
they format the help text. A regex match is less strict, but still makes some
assumptions about the implementation.
api/v1.AddFlags only supports a pflag.FlagSet. The assumption was that code
which wants to use flag.FlagSet can use VisitAll to copy the flags. That works,
with one caveat: the flag.FlagSet help implementation will call String for the
zero value to determine whether the flag has a non-default value. This
currently leads to additional warnings at the end of the -help output:
panic calling String method on zero v1.verbosityLevelPflag for flag v: runtime error: invalid memory address or nil pointer dereference
panic calling String method on zero v1.vmoduleConfigurationPFlag for flag vmodule: runtime error: invalid memory address or nil pointer dereference
Supporting usage of methods with the zero value is good practice anyway and
thus gets added. This then avoids these panics.
If we are dry-running, do not attempt to fetch the /version
resource and just return the stored FakeServerVersion,
which is done when constructing the dry-run client in
upgrade/common.go#getClient().
The problem here is that during upgrade
dry-run client reactors are backed by a dynamic client
via NewClientBackedDryRunGetterFromKubeconfig() and
for GetActions there seems to be no analog to
Discovery().Serverversion() resource for a dynamic client(?).
The kubeadm dry run client reactor code is flawed as it assumes
all invoked "get" verb actions can be casted to GetAction.
Apparently that is not the case when Discovery().ServerVersion()
and other discovery calls are made. In such cases the action
type is the bare ActionImpl.
Catch if an action can be casted to ActionImpl and construct a
GetAction from it. GetActionImpl only suppersets ActionImpl with
a Name field (empty string in this case).
Add unit test for Discovery().ServerVersion().
From the warning message that ginkgo now emits:
--slow-spec-threshold is deprecated --slow-spec-threshold has been deprecated
and will be removed in a future version of Ginkgo. This feature has proved
to be more noisy than useful. You can use --poll-progress-after, instead, to
get more actionable feedback about potentially slow specs and understand
where they might be getting stuck.
We already use --poll-progress-after.
The old tests were no longer passing with Ginkgo v2.5.0. Instead of keeping the
old approach of checking recorded spec results, now the tests actually cover
what we care about most: the results recorded in JUnit.
This also gets rid of having to repeat the stack backtrace twice (once as part
of the output, once for the separate backtrace field).
All information that we want will be written into the failure XML element's
data. We don't need the message tag and don't want it because our
tools (kettle, testgrid, spyglass) would then just concatenate the two strings.
This gets implemented for us by Ginkgo. However, truncating the failure message
is not supported there at the moment. It's unclear how important that is,
therefore this (recently added feature) gets removed.
