updatecli: converge both golang versions together

[v1v]

What

Use Microsoft Golang releases as the source of truth.

Why

This can avoid situations when the Go version is released earlier than the Microsoft Go version. And also simplify the automation.

Background

We use updatecli to determine when a new Golang release will be out. FIPS requirements enabled a new dependency; see #495. That introduced a change in where to look for releases and required fixing some issues: #571.

However, the changes that were applied didn't work smoothly, and PRs were partially created, see #623 (comment).

Consequently, I decided to change the implementation and rely on only the microsoft/go version; it might take a bit to be available, but that's the dependency we have by adding FIPS support.

Caveats

If this PR is merged, this will delay the golang crosbuild images for a new minor/patch until the Microsoft Golang release is out - last time took 1 day for 1.24.4-1 to be available.

If no actions are taken, and a new patch or minor release, then the golang autobump PR in this repository will be incomplete.

As far as I know, as long as the FIPS Microsoft is used in the golang crossbuild we cannot use a different approach, the autobuses PRs are atomic and should contain the golang versión and the sha for the amd64 and arm64 tar.gz files.

@pkoutsovasilis , let me know if this section provided enough context 🙇

Test

I created a branch called test-1.24.new-versioin that had the version 1.23.5 so I can test it works for 1.24.4

$ GITHUB_TOKEN=$(gh auth token) \                   
   GITHUB_ACTOR=v1v \
   BRANCH=test-1.24.new-versioin \
   GO_MINOR=1.24 \
   updatecli apply --config .github/updatecli.d/bump-golang.yml

Produced v1v#20

SUMMARY:
ACTIONS
========


Bump golang-version to latest version
  => [Automation] Bump Golang version to 1.24.4-1


Pull Request available at:

	https://github.com/v1v/golang-crossbuild/pull/20

Existing GitHub pull request found: https://github.com/v1v/golang-crossbuild/pull/20

=============================

SUMMARY:

⚠ Bump golang-version to latest version:
	Source:
		✔ [golangVersion] Get the Microsoft version of Golang, as it comes out a little later
		✔ [latestMicrosoftGoVersion] Get Latest Microsoft Go Release
		✔ [minor] Get minor version
	Condition:
		✔ [dockerTag] Is docker image golang:1.24.4 published
		✔ [is] Is version '1.24.4' not updated in 'go/Makefile.common'?
	Target:
		⚠ [update-go-makefile.common] Update go/Makefile.common
		⚠ [update-go-version] Update .go-version
		⚠ [update-go-versions] Update go version 1.24.4-1


Run Summary
===========
Pipeline(s) run:
  * Changed:	1
  * Failed:	0
  * Skipped:	0
  * Succeeded:	0
  * Total:	1

One action to follow up:
  * https://github.com/v1v/golang-crossbuild/pull/20

and if I retry it:

ACTIONS
========


Bump golang-version to latest version
  => [Automation] Bump Golang version to 1.24.4-1

Existing GitHub pull request found: https://github.com/v1v/golang-crossbuild/pull/20
Existing GitHub pull request found: https://github.com/v1v/golang-crossbuild/pull/20

=============================

SUMMARY:



✔ Bump golang-version to latest version:
	Source:
		✔ [golangVersion] Get the Microsoft version of Golang, as it comes out a little later
		✔ [latestMicrosoftGoVersion] Get Latest Microsoft Go Release
		✔ [minor] Get minor version
	Condition:
		✔ [dockerTag] Is docker image golang:1.24.4 published
		✔ [is] Is version '1.24.4' not updated in 'go/Makefile.common'?
	Target:
		✔ [update-go-makefile.common] Update go/Makefile.common
		✔ [update-go-version] Update .go-version
		✔ [update-go-versions] Update go version 1.24.4-1


Run Summary
===========
Pipeline(s) run:
  * Changed:	0
  * Failed:	0
  * Skipped:	0
  * Succeeded:	1
  * Total:	1

One action to follow up:
  * https://github.com/v1v/golang-crossbuild/pull/20

[mergify]

This pull request does not have a backport label. Could you fix it @v1v? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d is the label to automatically backport to the 1./d branch. /d is the digit
  NOTE: backport-skip has been added to this pull request.

[pkoutsovasilis]

@pkoutsovasilis , let me know if this section provided enough context 🙇

thank you @v1v that is more than enough on my end. Now I believe that the situation that we are in is clear to everybody.

Consequently, I decided to change the implementation and rely on only the microsoft/go version; it might take a bit to be available, but that's the dependency we have by adding FIPS support.

@ebeahan @pierrehilbert @cmacknz @dliappis please advise; Is the requirement of having a go version released first for the MSFT fork and only then being able to get golang-crossbuild images for upstream, acceptable? For the record, I wanna replay @v1v statistics here, indeed the last MSFT release was delayed only by 1 day. However, if anything changes with the MSFT fork or there is a delay in general for reasons we don't know/control, we won't get an upstream version without manual intervention

[v1v]

we won't get an upstream version without manual intervention

I think that won't be even possible manually for new minor or patches, the current implementation relies on two different sources.

Unless I miss something here

[pkoutsovasilis]

I think that won't be even possible manually for new minor or patches, the current implementation relies on two different sources.

Unless I miss something here

hmm you are 100% right @v1v this even requires manual intervention today, and this is yet another surprise to me 😆 Clearly I am not involved as much with FIPS and the MSFT fork and what are the expectations here. Thinking out loud since we produce different -fips container images, I cannot tell why we need to keep the two go versions tightly coupled.

[ebeahan]

Adding @simitt @ycombinator if they have context about FIPS, the MSFT fork, and what the expectations are here.

Will the eventual certification of FIPS 140-3 help simplify this situation with the two sources?

[ycombinator]

I'm in favor of using the version of https://github.com/microsoft/go as the source of truth.

If this PR is merged, this will delay the golang crosbuild images for a new minor/patch until the Microsoft Golang release is out - last time took 1 day for 1.24.4-1 to be available.

Yes, looking at their last few releases, they seem to generally be within a day of the upstream Go releases so I don't think we're introducing a huge delay.

Also, while we rarely have bugs due to changes in Golang, from a support perspective, if we use the same version of Golang for FIPS and non-FIPS builds, it would be one less variable we have to think about.

I also think it's easier from a development / maintenance perspective. If we kept the two versions independent, would we then need two variants of the .go-version file, using one for FIPS builds and the other for non-FIPS builds? This is probably a minor concern, but still one that could be avoided if we converge the Go versions by basing them on microsoft/go release versions.

[pkoutsovasilis]

@ycombinator @ebeahan definitely I am not trying to delay this PR, it just happened for me yesterday to realise the sequencing and I needed to make sure that we are on the same page. I feel that we all are now, so @ycombinator I leave the PR review up to you 🙂

[v1v]

@ycombinator @ebeahan and @pkoutsovasilis , can I get an approval here? This should solve the problem with partial updates. I've just found a new golang release, it worked partially for 1.24 but failed for 1.23.

[pkoutsovasilis]

I am not sure why noone approves this 😄 LGTM since I read all the comments of the stakeholders above