consider automating go-versions availability (auto go-versions update when released are done by the go team)

[ldemailly]

Description:
Trust the go team releases and have a minimal delay between the go team shipping a new patch release (e.g 1.20.6 to 1.20.7) and that patch becoming available with setup-go check latest actions - as in making go-versions update entirely automatic with no lag from humans

Justification:
Otherwise build break (in part because of govulncheck) or have to wait to release security fixed binaries

Are you willing to submit a PR?
I would but it's probably easier for someone familiar

There are a few hints on "how"

#405 (comment)

#405 (comment)

[dsame]

Hello @ldemailly , thank you for the input we will start review the suggestion in the near future.

[embano1]

The new tool management capabilities in 1.21 are slightly related to this discussion IMHO:

When you need a new version of a Go module, the go command downloads it for you. Starting in Go 1.21, when you need a newer Go toolchain, the go command downloads that for you too. This functionality is like Node’s nvm or Rust’s rustup, but built in to the core go command instead of being a separate tool.

If you are running Go 1.21.0 and you run a go command, say, go build, in a module with a go.mod that says go 1.21.1, the Go 1.21.0 go command will notice that you need Go 1.21.1, download it, and re-invoke that version’s go command to finish the build. When the go command downloads and runs these other toolchains, it doesn’t install them in your PATH or overwrite the current installation. Instead, it downloads them as Go modules, inheriting all the security and privacy benefits of modules, and then it runs them from the module cache.

https://go.dev/blog/toolchain

Do we need a discussion/consensus on if/how setup-go should use this new capability?

[silverwind]

It happened again with the go 1.21.8 / 1.22.1 release: #462

[ldemailly]

and now again with 1.21.9 and 1.22.2

[ldemailly]

Do we need a discussion/consensus on if/how setup-go should use this new capability?

Yeah as a user and having many repos with CI I think what the go team did is breaking the semantic of go version in go.mod it's been since day one language version without a patch level which implied a minimal version and obviously one wants all the patch/bug fixes as available - I, like others, highlighted the issue in golang/go#66175 (comment) and other issues)

ie I don't want to have to edit my go.mod each time a patch comes up - I want to say "go 1.21" in my setup and that means 1.21.9 as of today (which btw... it's 1.21.8 sadly) and ditto for 1.22 -> 1.22.2 - somehow 1.22 does end up starting with 1.22.1 and then getting 1.22.2 - see builds from fortio/workflows#15

[ldemailly]

meanwhile despite go-versions not having a PR, it works if you specify go1.22.2 (but it's cumbersome as mentioned before ^)

output

Setup go version spec 1.22.2
Attempting to resolve the latest version from the manifest...
matching 1.22.2...
Failed to resolve version 1.22.2 from manifest
Attempting to download 1.22.2...
matching 1.22.2...
Not found in manifest.  Falling back to download directly from Go
Install from dist
Acquiring go1.22.2 from https://storage.googleapis.com/golang/go1.22.2.linux-amd64.tar.gz
Extracting Go...
/usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/1a372f61-c[8](https://github.com/fortio/workflows/actions/runs/8545735206/job/23414664380#step:3:9)f6-443c-af49-e3ac60a30192 -f /home/runner/work/_temp/b6e2e65b-ea1b-484b-8c1e-d74820[9](https://github.com/fortio/workflows/actions/runs/8545735206/job/23414664380#step:3:10)04d08
Successfully extracted go to /home/runner/work/_temp/1a372f61-c8f6-443c-af49-e3ac60a30192
Adding to the cache ...
Successfully extracted go to /home/runner/work/_temp/1a372f61-c8f6-443c-af49-e3ac60a30192
Adding to the cache ...
Successfully cached go to /opt/hostedtoolcache/go/1.22.2/x64
Added go to the path
Successfully set up Go version 1.22.2

fortio/workflows#16