Bump golang to 1.23.1

[huww98]

external-snapshotter is already using 1.23.1 in go.mod

Bump Golang to 1.23.1

[k8s-ci-robot]

Welcome @huww98!

It looks like this is your first PR to kubernetes-csi/csi-release-tools 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-csi/csi-release-tools has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @huww98. Thanks for your PR.

I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[huww98]

BTW, do you think we should export GOTOOLCHAIN=local in run_with_go? If not, this function is meaningless because go will download the version specified in the go.mod itself. Or should we just remove run_with_go function and rely on go command to manage the version?

My opinion is adding GOTOOLCHAIN=local, so that build will fail if the go version specified in prow.sh is lower than go.mod. This should keep maximum reproducibility of CI result. go command will only upgrade, but not downgrade toolchain.

[huww98]

/cc @xing-yang @jsafrane
PTAL

[jsafrane]

/ok-to-test

[jsafrane]

BTW, do you think we should export GOTOOLCHAIN=local in run_with_go? If not, this function is meaningless because go will download the version specified in the go.mod itself. Or should we just remove run_with_go function and rely on go command to manage the version?

What approach does the main kubernetes/kubernetes use? Is there anything we could copy?

[huww98]

Maybe we can copy from kubernetes/kubernetes#120279

In short, k/k use:

• GOTOOLCHAIN=go$(cat .go_version) by default
• GOTOOLCHAIN=local if FORCE_HOST_GO is set

So maybe such a simple run_with_go should be sufficient:

# Ensure we use the desired version of the Go tools, then run command given as argument.
# Empty parameter uses the already installed Go. In Prow, that version is kept up-to-date by
# bumping the container image regularly.
run_with_go () {
    local version
    version="$1"
    shift
    if [ "$version" ]; then
        version=go$version
    else
        version=local
    fi
   GOTOOLCHAIN=$version run "$@"
}

and it works like this:

$ run_with_go "" go version
2024年11月 9日 星期六 00时59分35秒 CST go1.23.1 /Users/huww98/Downloads$ go version
go version go1.23.1 darwin/arm64

$ run_with_go "1.23.0" go version
2024年11月 9日 星期六 00时59分51秒 CST go1.23.0 /Users/huww98/Downloads$ go version
go version go1.23.0 darwin/arm64

$ run_with_go "1.23.2" go version
go: downloading go1.23.2 (darwin/arm64)
2024年11月 9日 星期六 01时01分21秒 CST go1.23.2 /Users/huww98/Downloads$ go version
go version go1.23.2 darwin/arm64

Please see #262

[pohly]

Manually downloading the right toolchain archive pre-dates the download mechanism in the Go toolchain itself. Nowadays using the toolchain to download the desired version is the right way to go.

[huww98]

Can we get this PR merged? Or should we fix the (seems unrelated) CI failure first?

[jsafrane]

We need the CI to be green before merge to make sure this PR does not break anything.

[jsafrane]

I am staring at the CI logs and they don't make much sense to me.

[pohly]

I suspect it fails because one or both repos are not completely present locally:

--filter=blob:none will filter out all blobs (file contents) until needed by Git

This is used in https://storage.googleapis.com/kubernetes-ci-logs/pr-logs/pull/kubernetes-csi_csi-release-tools/261/pull-kubernetes-csi-release-tools-external-snapshotter/1854867176855441408/clone-log.txt.

I'm not sure yet how to change this - will ask on Slack.

[huww98]

When cloning or fetching from a partial repository (i.e., one itself cloned with --filter), the server-side upload-pack may need to fetch extra objects from its upstream in order to complete the request. By default, upload-pack will refuse to perform such a lazy fetch

https://git-scm.com/docs/git-upload-pack

So I think set GIT_NO_LAZY_FETCH=0 should fix this.

Update: I think I've fixed this in the latest commit. Let's wait for it to turn green.

[jsafrane]

Almost, please also revendor.

[k8s-ci-robot]

@huww98: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubernetes-csi-release-tools-csi-test	fd153a9	link	false	/test pull-kubernetes-csi-release-tools-csi-test

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

[huww98]

@pohly @jsafrane Can you approve this PR? So that we can merge these two commits at once.

[pohly]

/lgtm
/approve

I think the whole "select Go version" logic needs further work, but in the meantime we can simply bump it.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: huww98, pohly

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 [pohly]

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

[huww98]

I think the whole "select Go version" logic needs further work, but in the meantime we can simply bump it.

@pohly for that part, please also help me review #262