Bump the go version to v1.23.2 for the GitHub workflows.

[Shubham82]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Bump the go version under GitHub workflow to 1.23.2, as Dockerfile and go.mod uses go version 1.23.2

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Shubham82
Once this PR has been reviewed and has the lgtm label, please assign mwielgus 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

[Shubham82]

Hi @gjtempleton @MaciekPytel
PTAL!

[adrianmoisey]

Any reason to not use 1.23.5 ?
Also, does this action need to install a specific version? What if it just installed latest?

[adrianmoisey]

Ah, I read the PR description and see the reason for this version

[Shubham82]

@adrianmoisey, to make the go version f.or ci pipeline for GitHub workflow use the same version as we used for our projects

[gjtempleton]

Question for a future improvement: Worth scripting something up to keep these versions in sync whenever we touch one of them? (Potentially an extension to the existing update-deps.sh?)

We also have one CI pipeline for all the projects under this repo, current drift at the head of the default branch is only one patch release, but we could be drifting further in the future - any risks here?

[Shubham82]

Question for a future improvement: Worth scripting something up to keep these versions in sync whenever we touch one of them? (Potentially an extension to the existing update-deps.sh?)

@gjtempleton, That sounds good. We can script this part so that the go version under ci.yaml will also be updated when we update other dependencies.

We also have one CI pipeline for all the projects under this repo, current drift at the head of the default branch is only one patch release, but we could be drifting further in the future - any risks here?

IMO, there is no risk, as projects used the go version corresponding to the latest k8s version.

VPA: https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/go.mod

@gjtempleton your thoughts?

[adrianmoisey]

We also have one CI pipeline for all the projects under this repo, current drift at the head of the default branch is only one patch release, but we could be drifting further in the future - any risks here?

IMO, there is no risk, as projects used the go version corresponding to the latest k8s version.

Is this a requirement? Is there value in the projects in this repo matching the k/k go version?

[Shubham82]

We also have one CI pipeline for all the projects under this repo, current drift at the head of the default branch is only one patch release, but we could be drifting further in the future - any risks here?

IMO, there is no risk, as projects used the go version corresponding to the latest k8s version.

Is this a requirement? Is there value in the projects in this repo matching the k/k go version?

Talking about CA, For every CA release, we update the corresponding upstream dependencies(k8s), so CA version and Kubernetes version have a one-to-one correspondence.
I think it is with VPA also, There was some talk of improvement in this area in vpa (#5759)

[adrianmoisey]

Talking about CA, For every CA release, we update the corresponding upstream dependencies(k8s), so CA version and Kubernetes version have a one-to-one correspondence.

What is the reason for this? Is there a need to have a one-to-one correspondence?

[Shubham82]

Hi @adrianmoisey
CA imports a huge chunk of internal k8s code because it calls out to the scheduler implementation. Therefore, to avoid version incompatibilities we keep the set of libraries used in CA as used by k8s.