🌱 Bump Kube API Linter version

[sivchari]

What this PR does / why we need it:

Bump Kube API Linter version, then the latest KAL changes its output format, so I updated configuration to ignore as is.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #11967

[sbueringer]

Let's have a separate PR to bump golangci-lint

[sivchari]

KAL uses golangci-lint v2.5.0 as dependency, so we should upgrade same version at least.

[sivchari]

/retest

[sbueringer]

KAL uses golangci-lint v2.5.0 as dependency, so we should upgrade same version at least.

KAL should have no dependency to the golangci-lint version we use in the action as far as I'm aware? It's an entirely separate binary (see Makefile: GOLANGCI_LINT_KAL)

[JoelSpeed]

Agreed, we shouldn't necessarily need to bump the golangci-lint version just because that's what KAL is using in its go.mod.

For the custom-gcl version that is being used here, that codepath only minimally depends on golangci-lint (registry import) and as such I would expect any v2.X to be fine (else someone merged something breaking)

Are you being forced to upgrade @sivchari ?

[sbueringer]

@JoelSpeed I think it's even more. I think KAL has 0 dependency on the golangci-lint binary we use in the action?

It should be built entirely independent of that. Or am I missing something?

[sivchari]

The below is the log which I tried to run make lint-api. Perhaps, You would be able to reproduce it.

make lint-api
GOBIN=/Users/takuma.shibuya/workspace/kubernetes/cluster-api/hack/tools/bin ./scripts/go_install.sh github.com/golangci/golangci-lint/v2/cmd/golangci-lint golangci-lint v2.4.0
# github.com/golangci/golangci-lint/v2/cmd/golangci-lint
ld: warning: -bind_at_load is deprecated on macOS
cd hack/tools; /Users/takuma.shibuya/workspace/kubernetes/cluster-api/hack/tools/bin/golangci-lint-v2.4.0 custom
WARN # github.com/golangci/golangci-lint/v2/pkg/golinters/embeddedstructfieldcheck
pkg/golinters/embeddedstructfieldcheck/embeddedstructfieldcheck.go:15:13: undefined: analyzer.ForbidMutexName
Error: build process: build golangci-lint binary: go build -ldflags -s -w -X 'main.version=v2.4.0-custom-gcl-47DEQpj8HBSaTImW5JCeuQeRkm5NMpJWZG3hSuFU' -X 'main.date=2025-11-17 07:38:04.723964 +0000 UTC' -o golangci-lint-kube-api-linter ./cmd/golangci-lint: exit status 1
The command is terminated due to an error: build process: build golangci-lint binary: go build -ldflags -s -w -X 'main.version=v2.4.0-custom-gcl-47DEQpj8HBSaTImW5JCeuQeRkm5NMpJWZG3hSuFU' -X 'main.date=2025-11-17 07:38:04.723964 +0000 UTC' -o golangci-lint-kube-api-linter ./cmd/golangci-lint: exit status 1
make: *** [/Users/takuma.shibuya/workspace/kubernetes/cluster-api/hack/tools/bin/golangci-lint-kube-api-linter] Error 3

KAL depends on golangci-lint v2.5.0, and golangci-lint v2.5.0 upgrades version about embeddedstructfieldcheck in this. These upgrades change definition fromanalyzer.ForbidMutextName to analyzer.ForbidMutexCheck ref.
And then golangci-lint custom try to build new binary with go build. So if the build process could be failed bacause of the difference between v2.4.0 and v2.5.0. So I think we should also bump golangci-lint version to bump latest version of KAL.

[sbueringer]

Just to avoid misunderstandings.

I'm suggesting to revert the change to .github/workflows/pr-golangci-lint.yaml but keep the one in hack/tools/.custom-gcl.yaml.

It's entirely unclear to me how the version number in .github/workflows/pr-golangci-lint.yaml would influence the build of the KAL binary. These should be 100% independent as far as I can tell

[sbueringer]

For me make lint-api works when I change .github/workflows/pr-golangci-lint.yaml to v2.4.0.

(I know it seems unimportant, but I would like to figure out if we really have to keep our regular golangci-lint and KAL 100% in sync, which would be very annoying)

[sivchari]

The lint CI was passed, so the problem seems to be happened in only my environment. Sorry.

[sivchari]

I just tried it again and it worked. It might have been conflicting with something in another branch. The reason isn't clear, though.

[JoelSpeed]

@JoelSpeed I think it's even more. I think KAL has 0 dependency on the golangci-lint binary we use in the action?

It should be built entirely independent of that. Or am I missing something?

Yes, as long as the environment running the KAL custom binary build has some version of golangci-lint V2, it doesn't matter that what's in the custom matches what's in the workflow

[sbueringer]

Ah is the KAL custom binary using golangci-lint from the path? I always assumed that this is a standalone binary

[JoelSpeed]

We call golangci-lint custom to build KAL, which then downloads a copy of golangci-lint and KAL and compiles it.

IMO we probably want to switch to the go plugin version (many others are) but that then also depends on the version of golangci-lint in the path. We could also look at building from the cmd package to create the custom binary now that's been added, then there wouldn't be a dependency on golangci-lint in the path, but would tie the tools go.mod to a golangci-lint dependency

[JoelSpeed]

Just as an aside, why didn't we add list type atomic to these? Because it conflicts with the expectations of the conditions linter I expect?

[sbueringer]

I think for this exclude here we didn't want to take any risk making a change to the deprecated condition field at this point.

These fields will be removed in the foreseeable future anyway.

For the new condition fields we want to support co-ownership

[sivchari]

If there are something that I need to do, please let me know (I think it seems to be ready to merge)

[sbueringer]

All good. Thx!

/lgtm
/approve

Might be also nice to be able to just consume KAL as a binary instead of compiling it ourselves

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 001ab65ab32d06529b24afc890c4aed657601efb

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sbueringer]

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