@mengzhuo Since the riscv64 patch was contributed by you, maybe you can review this change. I haven't encounter the problem when building in other platform.

FYI:
golang/go#57631 means go.mod version should be explicitly with minor version go 1.24.0 instead of adding a toolchain go1.24.2

How the toolchain dependency is managed?

For example: if go 1.24.1 has security fixes, then will go 1.24.0 insist to use 1.24.0, or will use the latest one like 1.24.1 or even 1.24.10?

How the toolchain dependency is managed?

For example: if go 1.24.1 has security fixes, then will go 1.24.0 insist to use 1.24.0, or will use the latest one like 1.24.1 or even 1.24.10?

The mod treat go directive as "a required minimum version" instead of a CVE mandatory version.
Please check the mod document for further information.
https://go.dev/ref/mod

Why should we specify minimum version >=1.24.2 when we are compatible with >=1.24. Someone using 1.24.1 or 1.24.2 would not be able to build.

If anything, I would specify 1.24.0 which should be equivalent to 1.24 as far as go is concerned (I know the go tooling has a number of bugs surrounding this .0 suffix, and I think they will only be fixed come 1.25).

ci check failed because of security issues in 1.24.{0,1}

ci check failed because of security issues in 1.24.{0,1}

It shouldn't fail with go 1.24.0 in go.mod because I think setup-go will always use the highest possible patch version, right?

Ah, it appears setup-go makes a difference between 1.24 and 1.24.0:

https://github.com/actions/setup-go#getting-go-version-from-the-gomod-file

If a patch version is specified, that specific patch version will be used.
If no patch version is specified, it will search for the latest available patch version in the cache, versions-manifest.json, and the official Go language website, in that order.
If both the go-version and the go-version-file inputs are provided then the go-version input is used.

This is very undesired behaviour, but I think it's unlikely they'd want to change it.

I guess the best course of action is either not specifying a patch version in go.mod or specify a patch version in go.mod and add a go-version-file with the 1.24 format to get the auto-updating behaviour (so we don't have to update go.mod on every patch release).

Ah, it appears setup-go makes a difference between 1.24 and 1.24.0:

https://github.com/actions/setup-go#getting-go-version-from-the-gomod-file

If a patch version is specified, that specific patch version will be used.
If no patch version is specified, it will search for the latest available patch version in the cache, versions-manifest.json, and the official Go language website, in that order.
If both the go-version and the go-version-file inputs are provided then the go-version input is used.

This is very undesired behaviour, but I think it's unlikely they'd want to change it.

I guess the best course of action is either not specifying a patch version in go.mod or specify a patch version in go.mod and add a go-version-file with the 1.24 format to get the auto-updating behaviour (so we don't have to update go.mod on every patch release).

This method seems to only support setup-go, if I want to run it locally I still need to fix the go version to 1.24.2.

Thanks for your first PR to the project! I think since we will have to bump go.mod regardless, and since actions/setup-go doesn't immediately bump its known latest version we sometimes have to wait on it when go patches are released, so we can skip go-version-file