The golangci-lint docs indicate that, for gocritic, disabled-checks
and enabled-checks can't be combined. That is however not accurate;
enabled-checks adds checks, disabled-checks disables them, in that
order. If disable-all isn't set, then the setup starts with the checks
enabled by default, adds any additional checks specified in
enabled-checks, and removes checks specified in disabled-checks.
This means that instead of filtering unwanted checks, we can disable
them entirely. This makes the set of disabled checks easier to read,
and perhaps easier to clean up in future.
For singleCaseSwitch and wrapperFunc, we only want to ignore specific
instances, so this is still done by filtering.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
Include defaulting in the StatefulSet fuzzer for the field
RollingUpdate.MaxUnavailable, otherwise when the feature gate
MaxUnavailableStatefulSet is enabled it changes the default
in SetDefaults_StatefulSet from /pkg/apis/apps/v1/defaults.go.
That can cause errors such as:
--- FAIL: TestRoundTripTypes (1.05s)
...
- MaxUnavailable: nil,
+ MaxUnavailable: s"1",
In the device plugin node reboot e2e test, the test previously waited a
short period for the resources exported by the sample device plugin to
appear on the local node. On slower test nodes, the plugin may take
longer to register, causing flakes where the expected devices are not
yet available.
This change increases the polling duration to 2 minutes, ensuring the test
waits long enough for the expected device capacity and allocatable resources
to appear, improving test stability.
This commit also updates the assertion message to be more explicit making
failures clearer and improving test reliability.
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
In the device plugin node reboot e2e test, the registration trigger
(control file deletion) was being executed immediately after pod creation.
This could create a race condition: the device plugin container might not
be fully running, causing the test to flake when devices were not reported
as available on the node.
This change explicitly waits for the sample device plugin pod to reach the
Running/Ready state before deleting the registration control file. This
ensures that the device plugin is ready to register its devices with the
kubelet, eliminating a possible source of test flakiness.
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>
The spec is the same in both, so those fields are now handled by common
code. For ResourceClaim spec updates, the "in use" check now only considers
the spec.
Theoretically some features could be in use in an old ResourceClaim status
and not in use in the spec. This can only occur in a spec update, which is
currently prevented because the entire spec is immutable. Even if it was
allowed, preventing adding disabled fields to the spec is the right thing to
do regardless of what may have ended up in the status earlier.
