Add makefile entries for api-lint

[rikatz]

This PR adds the makefile entries for Kube api linter, as discussed during WG Inference meeting.

The linter now can be called locally using make verify or make api-lint.

A lint-fix wasn't added, as it is expected that the fixes are discussed and not automatically fixed.

Fixes: #1380

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	e0a7f1a
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68a32c029e6c6d0008dcf8c6
😎 Deploy Preview	https://deploy-preview-1384--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rikatz
Once this PR has been reviewed and has the lgtm label, please assign kfswain for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[rikatz]

/hold

I will submit a broken change just to guarantee KAL is running

[rikatz]

Bad run output: https://github.com/kubernetes-sigs/gateway-api-inference-extension/actions/runs/16977153553/job/48128874167?pr=1384

And on prow:
https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/kubernetes-sigs_gateway-api-inference-extension/1384/pull-gateway-api-inference-extension-verify-main/1956106235279314944

[rikatz]

/hold cancel

[BenTheElder]

Maybe make the CI use this so you know local and CI invocations are in sync?

[rikatz]

Maybe make the CI use this so you know local and CI invocations are in sync?

hey Ben, the verify-main prow job uses it, but good catch. I will change the github action one to use make api-lint instead.

[nirrozenbaum]

make verify runs as a pre submit check on every PR. now that api-lint was added to the makefile, do you think this workflow is needed?

[rikatz]

I wanted to keep it on Github action as:

• It is faster than prow job (we can remove from make verify later or make prow use a different target, as make verify was actually my attempt to add it to the developer workflow as well
• The github action is able to annotate the PR directly telling where are the files (as per the screenshot above)
  wdyt? I think for now it doesn't hurt to have both prow job and the github action running, and we do some followup clean up on the prow job

[nirrozenbaum]

personally I like to have it in makefile without github workflow which allow users to run it locally in their envs with no surprises later in ci. as you probably noticed we have no github workflows, everything runs through the make verify which makes it repeatable in local envs.

I think it’s cleaner, but not feeling strongly about it.

[robscott]

I think the benefits of using GitHub actions here (remarkably fast/lightweight presubmits, clearer feedback directly on the PR) has outweighed any potential disadvantages in our experience in Gateway API. I agree that we should also aim to have a make task that can verify everything locally as well, but would hate to require the structure of our presubmits to directly match that as it could become quite slow over time. It can be much more efficient to split out parts of the verification into separate presubmits.

[nirrozenbaum]

@robscott you touched two different points:

1. running different parts of verification in separate presubmit checks for parallelism. that could be done using make commands and just adding make api-lint as another pre-submit check that runs in parallel to make verify. this is easy to do.
2. running this specific check in github action, which is faster than make command.

let's assume we go with parallelism, so it's either we run another make command in parallel or using github action.
now the question is whether the fact that the action is faster is worth having it (github actions cannot run in local envs, so checks may drift as we make progress).
since we anyway have to wait for the longest pre-submit check which is the tests themselves, when looking at the tradeoff I prefer having an identical setup or at least a way to run it identically locally (e.g., make verify api-lint) rather than having a super fast action, but the other pre-submit checks take long.

but again, not feeling very strongly about it. if you feel strongly about having a github action, let's go with that.

[rikatz]

As a suggestion, I can remove the api-lint from verify target, and make the github action call make api-lint directly.

My addition of api-lint to verify was mostly as @danehans raised correctly that as a developer, sometimes I just do a make verify on the repo and expect that all of the validations run.

We can probably add to some doc that the api-lint is a different target, or eventually create a new target that should be called by prow, and will contain all verify targets but api-lint.

So a developer doing make verify will get the full package, the CI doing make ci-verify will do all but api-lint, and api-lint is called by github action.