Synchronizing golang version from test -> release binary builds

[cevich]

Problem:

Both the Windows and MacOS release build->sign->publish workflows hard-code a golang version which will be hard to maintain, and may not reflect what was used during CI testing.

Background:

• It's really (really) important to properly secure the required Windows and MacOS signing keys used to mark the built packages as "trusted".
• It's really hard (and/or complex) to secure them in Cirrus-CI (since tasks can be modified in a PR)
• It's somewhat easier to secure them for a github-actions workflow (since it can be made to never run in/from/for a PR).
• Building & publishing binaries from a github-action requires setting the golang version.
• Synchronizing automation tasks between Cirrus-CI and Github-Actions is possible, but quite complex (i.e. otherwise there's no guarantee a cirrus task will finish before a github workflow does, or vis versa).

[cevich]

As a starting point. The "simplest" solution I can come up with is to update the github-action build workflows to:

1. Look up the IMAGE_SUFFIX from the checked out .cirrus.yml file.
2. Run go env GOVERSION in quay.io/libpod/fedora_podman:$IMAGE_SUFFIX.
3. Parse and extract the golang version from the output.
4. Use the extracted golang version as the go-version value in the actions/setup-go action step.

[nalind]

go help version suggests that running go version against the copy of podman in question would be more accurate.

[cevich]

Another idea (inspired by some of Ed's past work):

1. Add/add-to a cirrus-task that exit(1) (with a helpful message) any time it detects it's building podman with a golang version that doesn't match go-version in upload-win-installer.yml or mac-pkg.yml
2. Sit back, relax, and rest assured somebody will get bothered by this when it's appropriate.

[nalind]

If the goal is to keep using the current version of Go, https://github.com/actions/setup-go offers "stable" as a value for "go-version".

[cevich]

I'm not 100% sure that's the case? Ideally, what we release == what we tested. However, release binaries have been disconnected from the CI environments for quite some time, so maybe you're right?

Maybe a Makefile level check against a build_with_go_version file's contents could work. It would be trivial to grab the version from that file and use it within the github actions.

[Luap99]

Go is pretty stable I am not worried that a (supported) version will cause problems for us. So as long as we update the version it should work. Also current CI also juts uses what is in fedora which is usually the last two supported versions so it should match one of those normally.

Then if this is just for the windows/macos installers then the answer is we do not test them at the moment anyway so there is nothing to match. And then the remote client is a simple http client and a VM manager, I find it unlikely that we have to worry about the go version.

So I think as @nalind suggest using stable sounds good to me so we do not need to keep them up to date anyway.

[cevich]

Opened: #19450