feat: add kube api linter in kagent

[dongjiang1989]

Add kube-api-linter: https://github.com/kubernetes-sigs/kube-api-linter

Fix

• Added the // +kubebuilder:optional marker to the Conditions field in the status struct to comply with Kubernetes API conventions and pass kube-apilinter validation.
• Removed the conflicting +kubebuilder:required marker.
• Kept +kubebuilder:default:=xxx and added the explicit +kubebuilder:optional marker to comply with Kubebuilder validation rules.

[Copilot]

Pull request overview

Adds kube-api-linter (via a custom golangci-lint build) to the Go module to enforce Kubernetes API/CRD marker conventions, and updates CRD types to comply with the new linting rules.

Changes:

• Introduce a custom golangci-lint binary with the kube-api-linter plugin plus a dedicated .golangci-kal.yml config.
• Add make lint-api / lint-api-fix targets and wire them into CI.
• Update multiple CRD API types (v1alpha1/v1alpha2) with +optional / +required markers and related tweaks.

Reviewed changes

Copilot reviewed 28 out of 29 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
go/go.mod	Adds kube-api-linter/tooling dependencies and a tool directive for the custom builder.
go/go.sum	Updates dependency checksums for newly introduced tooling deps.
go/Makefile	Adds targets to build/run a custom golangci-lint with kube-api-linter and a clean step.
go/.golangci-kal.yml	New golangci-lint config intended to run kube-api-linter on API packages.
go/.custom-gcl.yaml	Defines the custom golangci-lint build and plugin pinning.
.github/workflows/ci.yaml	Adds a new api-lint job to run kube-api-linter in CI.
Makefile	Adds a repo-level lint-api target delegating to go/Makefile.
go/api/v1alpha2/*.go	Adds/adjusts kubebuilder markers on v1alpha2 CRD types.
go/api/v1alpha1/*.go	Adds/adjusts kubebuilder markers on v1alpha1 CRD types.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dongjiang1989]

cc @EItanya PTAL, thanks

[EItanya]

Thanks so much for adding this. Why not just include this linter config inside of the existing linter config?

[dongjiang1989]

Thanks so much for adding this. Why not just include this linter config inside of the existing linter config?

Thanks @EItanya
We separated this linter config to keep the main config clean and focused on common rules. This check is specific to our scenario, so a dedicated config is easier to manage and won’t affect other users of the shared configuration.

[EItanya]

Thanks so much for adding this. Why not just include this linter config inside of the existing linter config?

Thanks @EItanya We separated this linter config to keep the main config clean and focused on common rules. This check is specific to our scenario, so a dedicated config is easier to manage and won’t affect other users of the shared configuration.

What do you mean other users? This linting is for the project as a whole so I don't see the differece

[dongjiang1989]

What do you mean other users? This linting is for the project as a whole so I don't see the differece

I understand your point. I split the config mainly to isolate the Kubernetes API linter rules, so it won’t impact the existing general lint workflow for all contributors.

[EItanya]

What do you mean other users? This linting is for the project as a whole so I don't see the differece

I understand your point. I split the config mainly to isolate the Kubernetes API linter rules, so it won’t impact the existing general lint workflow for all contributors.

Let’s combine them

[dongjiang1989]

Let’s combine them

Thanks @EItanya
Changed. Please re-check it