go.mod: update to go v1.22

[achilleas-k]

• Update the go.mod to use v1.22
• Update all test workflows to install v1.22
• Edit and run tools/prepare-source.sh

[schuellerf]

LGTM, although there are some places where we just dnf install go
which might cause inconsistent test results?
(e.g. test/scripts/install-dependencies or .github/workflows/test-osbuild-composer-integration.yml)
should we pin those too, in a followup PR?

[achilleas-k]

No need. Those run on distros with new enough Go versions so there shouldn't be an issue.

Go version pinning isn't really important. It shows up in the GitHub actions because we use the action that supports pinning. Then there's the prepare-source.sh, which is pretty much a historical artifact now but serves mostly to avoid bumping the Go version accidentally when doing go mod stuff (which I think used to happen but doesn't anymore). As long as we have at least one GH action that make sure everything compiles correctly with our target Go version, it's fine.

[schuellerf]

My thinking was rather that tests might behave differently e.g. a test could succeed in a newer go version but fails in the pinned/released older version

[supakeen]

My thinking was rather that tests might behave differently e.g. a test could succeed in a newer go version but fails in the pinned/released older version

How do you mean? Go generally uses this version to enable/disable language features so they cannot be used; even when compiled with a newer Go.

[schuellerf]

Probably saw to many odd behaviors with different compiler version just creating different results.
Searching a problem in production where the test (running the new compiler) was green but due to some odd bug only apparent when using the old compiler version in the release process feels scary, I guess.
This would probably fail in other tests as some might be repeated during the release process 🤔
If there wouldn't be the possibility for strange bugs like this, there wouldn't be releases of golang anymore X-D

[achilleas-k]

Probably saw to many odd behaviors with different compiler version just creating different results. Searching a problem in production where the test (running the new compiler) was green but due to some odd bug only apparent when using the old compiler version in the release process feels scary, I guess.

But we do test with the supported version. It's just that we do manifest generation in Gitlab with whatever's in the Fedora repos. If compiling with a newer Go version generates a different manifest, that'd be a pretty serious compiler issue, I think.