What happens
Three more kinds have a top-level spec that is neither required nor defaulted, so an object applied with no spec key is accepted and none of the nested defaults apply:
notes.miloapis.com/v1alpha1 Note, nested default on followUpnotes.miloapis.com/v1alpha1 ClusterNote, nested default on followUpnotification.miloapis.com/v1alpha1 Email, nested default on priority
Same defect class as #773 (ServiceAccount, fixed in #774) and #775 (PlatformAccess and UserPreference, in #778). Found during review of #778.
Fix
For each kind, pick one:
- Add
+kubebuilder:default={} to the Spec field and regenerate, when every required sub-field has a default or spec has no required sub-fields.
- Mark
spec required, when a required sub-field has no default.
Add each kind to the table-driven schema test that #778 introduces so the choice cannot regress.
Related to #775.
What happens
Three more kinds have a top-level
specthat is neither required nor defaulted, so an object applied with nospeckey is accepted and none of the nested defaults apply:notes.miloapis.com/v1alpha1Note, nested default onfollowUpnotes.miloapis.com/v1alpha1ClusterNote, nested default onfollowUpnotification.miloapis.com/v1alpha1Email, nested default onprioritySame defect class as #773 (ServiceAccount, fixed in #774) and #775 (PlatformAccess and UserPreference, in #778). Found during review of #778.
Fix
For each kind, pick one:
+kubebuilder:default={}to theSpecfield and regenerate, when every required sub-field has a default or spec has no required sub-fields.specrequired, when a required sub-field has no default.Add each kind to the table-driven schema test that #778 introduces so the choice cannot regress.
Related to #775.