Support using a later patch release than what's in go.mod

[perj]

Description: Some packages (e.g. k8s.io/apimachinery) puts go 1.22.0 in their go.mod file. This propogates to applications using it, which also gets go 1.22.0 in go.mod. Setup-go will then find that exact version. I would like a flag, possibly enabled by default, to instead use the latest patch version, as long as it's greater than the one in go.mod.

Justification: Using 1.22.0 could be a security risk. Before our go.mod was changed to say go1.22.0, setup-go was using 1.22.3, now it's downgraded. We can solve this by manually setting go1.22.3, but we can't set go1.22 since that's considered lower than 1.22.0, so there's no way to say "use latest version" via go.mod right now.

Are you willing to submit a PR? Yes, possibly, but it will probably take me a while to make it a priority.

[HarithaVattikuti]

Hello @perj We appreciate your suggestion for a new feature! We'll make sure to address it when we have the opportunity.

[magnetikonline]

Thanks for raising this @perj - this is bang on the same issue I'm seeing.

Would like the option to ignore the "patch" component of a given go VERSION line - and use the latest version (ideally already pre-loaded on a GitHub Actions public runner - avoid the download) and only consider the MAJOR.MINOR components.

[bconway]

I would also like to see this. Additionally, I think the docs may be wrong here:

The go directive in go.mod can specify a patch version or omit it altogether (e.g., go 1.22.0 or go 1.22).

Setting my go.mod to not include a patch version throws errors in various tools and instructs me to run go mod tidy ,which adds back the .0.

$ go build ./...
go: updates to go.mod needed; to update it:
        go mod tidy

[kaovilai]

Setting my go.mod to not include a patch version throws errors in various tools and instructs me to run go mod tidy ,which adds back the .0.

Not having .0 is valid, you just have to not depend on ANY deps that requries go X.X.0.

At go 1.21 or higher: The go line declares a required minimum version of Go to use with this module. The go line must be greater than or equal to the go line of all dependencies. The go command no longer attempts to maintain compatibility with the previous older version of Go. The go command is more careful about keeping checksums of go.mod files in the go.sum file. https://go.dev/ref/mod#go-mod-file-go

Example of projects that can go mod tidy without adding .0

https://github.com/search?q=org%3Agolang+path%3Ago.mod+%22go+1.24%22+NOT+%22go+1.24.0%22&ref=opensearch&type=code

[kaovilai]

If not having .0 always works.. then this issue is less urgent.

[kaovilai]

@bconway you can check which module you require forces upon you that .0 by

❯ go mod graph | grep [email protected]
github.com/vmware-tanzu/velero [email protected] // ignore the first line, that's your own module requiring go1.23.0 as a result of lines below.
[email protected] [email protected]
golang.org/x/[email protected] [email protected]
golang.org/x/[email protected] [email protected]
golang.org/x/[email protected] [email protected]

If you have no lines other than your own module name then you don't actually need that .0

[bconway]

Not having .0 is valid, you just have to not depend on ANY deps that requries go X.X.0.

Is that plausible in the real world, though? Your examples are all in the standard library.

[kaovilai]

Depends what you depends on. Here's another https://github.com/go-macaron/macaron/blob/main/go.mod

[kaovilai]

More examples https://github.com/search?q=path%3Ago.mod+%22go+1.24%22+NOT+%22go+1.24.%22+NOT+org%3Agolang&ref=opensearch&type=code

[kaovilai]

You can also bark up the chain, ask all your deps to drop .0

[kaovilai]

but yes if at least one fail to drop .0, you will acquire .0