Enable the optionalorrequired linter for the apidiscovery API group#137075
Enable the optionalorrequired linter for the apidiscovery API group#137075vinayakray19 wants to merge 2 commits intokubernetes:masterfrom
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hi @vinayakray19. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vinayakray19 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
What type of PR is this?
/kind api-change
/kind feature
What this PR does / why we need it:
Which issue(s) this PR is related to:
Fixes : #136859
Special notes for your reviewer:
This PR enables the optionalorrequired kube-api-linter rule for the apidiscovery API group as tracked in #136859
To support this change, all fields in the apidiscovery API types have been annotated with explicit markers (+required or +optional) in accordance with Kubernetes API conventions.
The adjustments do not alter API semantics, behavior, or compatibility; they only satisfy static analysis requirements enforced by the linter.
The optionalorrequired rule ensures that every API field is explicitly marked as either optional or required, improving API clarity and future maintainability.
Does this PR introduce a user-facing change?
No.