Refactor TestVersionedValidationByFuzzing to use a declarative map,
subresourceOnly, for resources that must be validated via a specific
subresource path (like autoscaling/Scale).
GVKs not in this map default to root-level validation (""), which is
sufficient for resources that share validation logic between their root
and subresources. This replaces the previous ad-hoc special-casing
with a cleaner, extensible mapping.
Fuzzing must be performed on the internal version of objects because
custom fuzzing functions are typically registered for internal types.
This ensures that all fields are properly initialized with random values
before being converted to various API versions for validation.
Move fuzzing logic into VerifyVersionedValidationEquivalence via a new
WithFuzzer option. This also fixes a panic that occurred when attempting
to fuzz types without an internal version (e.g., APIGroupList) by adding
a nil check after internal conversion.
This commit adds an 'IgnoreObjectConversionErrors' option to the
validation testing framework in 'k8s.io/apimachinery' and exposes it
via 'pkg/api/testing'.
This is useful for fuzzing tests where we might want to skip object
versions that cannot be converted from the internal version (e.g. due to
missing fields or incompatible types in older versions) but still want
to test validation for the versions that *can* be converted.
The 'autoscaling' group versions are added to 'TestVersionedValidationByFuzzing'
with this option enabled.
Introduces new testing helpers to simplify testing of declarative validation rules. The new `VerifyValidationEquivalence` and `VerifyUpdateValidationEquivalence` functions reduce boilerplate by encapsulating the logic for:
- Toggling the `DeclarativeValidation` and `DeclarativeValidationTakeover` feature gates.
- Comparing the validation output from the imperative and declarative paths.
The declarative validation tests for CertificateSigningRequest and ReplicationController are updated to use these new, simpler helpers.
This adds the "DeviceTaint" top-level type to v1alpha3 and related fields to
ResourceSlice and ResourceClaim. It's complete enough bring up an API server
and generate files.
This makes a bold assumption: that the errors (count and basic content)
will be the same across versions. If this turns out to be untrue, this
may need to get more sophisticated. It should fail obviously when we
hit that edge.
