Skip to content

Add Kubernetes API Linter to kueue-operator#1282

Open
kannon92 wants to merge 1 commit intoopenshift:mainfrom
kannon92:add-kal-linter
Open

Add Kubernetes API Linter to kueue-operator#1282
kannon92 wants to merge 1 commit intoopenshift:mainfrom
kannon92:add-kal-linter

Conversation

@kannon92
Copy link
Contributor

@kannon92 kannon92 commented Jan 11, 2026

This should help enforce standards on new API changes similar to openshift/api.

This is not yet included in CI but we can at least allow people to run it on some PRs like #1266 or #1213.

@openshift-ci openshift-ci bot requested review from PannagaRao and mrunalp January 11, 2026 19:36
@openshift-ci
Copy link

openshift-ci bot commented Jan 11, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kannon92

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 11, 2026
@kannon92 kannon92 force-pushed the add-kal-linter branch 4 times, most recently from 44390a0 to 4a400db Compare January 13, 2026 19:30
// spec holds user settable values for configuration
// +required
Spec KueueOperandSpec `json:"spec"`
Spec KueueOperandSpec `json:"spec,omitzero"`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoelSpeed @everettraven

Is there any concerns on breaking changes for omitzero or omitempty?

I don't have any CRD changes but I guess its worth asking if there could be any UX issues with adding these tags.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is going to be safe. Looking through, I can see that the empty marshalled spec object would have been rejected by the fact you have at least 1 required field that doesn't permit its empty value in the spec.

So previously a user who set nothing, would have marshalled the empty object, and got a rejection. Now, they wouldn't marshal anything, and would still get a rejection

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Joel!

- ["default", "kubebuilder:default"]
- ["required", "kubebuilder:validation:Required", "k8s:required"]
description: "A field with a default value cannot be required"
conditions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed a couple of differences from upstream, is this expected?
https://github.com/kubernetes-sigs/kueue/blob/main/.golangci-kal.yml#L50-L61

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed up a change for conditions so it matches.

@cpmeadors
Copy link
Contributor

FWIW, the make targets worked for me. I will defer to others with comments.

@openshift-ci
Copy link

openshift-ci bot commented Jan 28, 2026

@kannon92: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions 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. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants