Bump go mod version from 1.22 to 1.22.0 to fix toolchain download issue

[cmoulliard]

Description

TL&DR
Pack cannot be build in an hermetic and containerized environment as the version of go 1.22 declared within the go.mod file do not correspond to a toolchain version 1.22.0 - see: https://go.dev/blog/toolchain

---

Such a limitation comes from Golang itself how it processes go.mod files. When Go sees the language version, but not a toolchain version, i.e. 1.22 vs 1.22.0 it's not going to be able to download a correct toolchain for the given language version. Go community is aware of that problem and they fixed it in 1.23 so that the inference of the .0th toolchain from a particular language version works.

Proposed solution

Bump the go version defined within the go.mod file

Additional context

See error reported when building pack in an hermetic and containerized environment

[jjbustamante]

@cmoulliard I have a question about this.

If we bump the go mod version to 1.22.0 will this affect the workflow version when we are compiling the tool here? If I am not wrong, we are using the check-latest option which uses the latest go fix version 1.22.x.

For example, on my machine, I can see the latest pack version was compiled using go 1.22.5

>$ which pack
/home/linuxbrew/.linuxbrew/bin/pack
>$ go version /home/linuxbrew/.linuxbrew/bin/pack
/home/linuxbrew/.linuxbrew/bin/pack: go1.22.5
>$ pack version
0.35.1+git-3a22a7f.build-6099

If we set the go.mod to 1.22.0 does it mean the go-setup action will use go 1.22.0?

[cmoulliard]

If we bump the go mod version to 1.22.0 will this affect the workflow version when we are compiling the tool here?

I'm not a go expert but I don't think so as according to the documentation of the toolchain - https://go.dev/doc/toolchain

"In the standard configuration, the go command uses its own bundled toolchain when that toolchain is at least as new as the go or toolchain lines in the main module or workspace.

For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.0, the go command uses Go 1.21.3.

When the go or toolchain line is newer than the bundled toolchain, the go command runs the newer toolchain instead. For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.9, the go command finds and runs Go 1.21.9 instead.

It first looks in the PATH for a program named go1.21.9 and otherwise downloads and caches a copy of the Go 1.21.9 toolchain.

This automatic toolchain switching can be disabled, but in that case, for more precise forwards compatibility, the go command will refuse to run in a main module or workspace in which the go line requires a newer version of Go. That is, the go line sets the minimum required Go version necessary to use a module or workspace."

[jjbustamante]

I will try to test the github action to double check how it behaves

[cmoulliard]

I will try to test the github action to double check how it behaves

Have you been able to test ?

[jjbustamante]

@cmoulliard oh man, no! sorry

[natalieparellano]

Summarizing other conversation with Juan: we need to check if providing the toolchain in go.mod will lock us to a go version when running actions/setup-go. Ideally we'd like to preserver the ability to automatically upgrade to the latest go patch when we run our pipelines

[cmoulliard]

Ideally we'd like to preserver the ability to automatically upgrade to the latest go patch when we run our pipelines

You can keep the control par of the github action over what you would like to use as go distribution. See: https://github.com/actions/setup-go?tab=readme-ov-file#v3

From a development, testing and releasing point of view, if you decide to align the code to 1.21, then this is a good practice to use now the new convention and to build using latest patch version available if some CVEs, etc have been fixed => example: 1.21.13