ci/cirrus: use Go 1.19.x not 1.19

[kolyshkin]

This variable is used in curl to download a go release, so we are using the initial Go 1.19 release in Cirrus CI, not the latest Go 1.19.x release.

From the CI perspective, it makes more sense to use the latest release, so let's use 1.19.x here.

Add some shell jq magic to extract the latest minor release information
from the download page, and use it.

This brings Cirrus CI jobs logic in line with all the others (GHA,
Dockerfile), where by 1.20 we actually mean "latest 1.20.x".

Previous commits touching this:

• 5ecd40b 1.19
• 5211cc3 1.18 <-- I blame the author of this one 😄
• 12a3626 1.17.3
• 9f656db 1.16.6

[thaJeztah]

If we have jq as option, we could use the JSON feed; https://go.dev/dl/?mode=json&include=stable

There's probably some docs somewhere about that URL (it looks like include=stable only returns stable versions, and the first entry would have the version at least (but first entry is "source", so we probably need to filter on os/arch).

There's some scripts used for the official Golang image on Docker Hub that may be useful; https://github.com/docker-library/golang/blob/e8e87a35e7de2343770e13ec1b6c62cafb95728d/versions.sh

[kolyshkin]

I found the docs! https://pkg.go.dev/golang.org/x/website/internal/dl

[kolyshkin]

[kir@kir-rhat runc]$ PREFIX=https://golang.org/dl/
[kir@kir-rhat runc]$ GO_VERSION=1.20
[kir@kir-rhat runc]$ eval $(curl -fsSL "${PREFIX}?mode=json" | jq -r  --arg Ver "$GO_VERSION" '.[] | select(.version | startswith("go\($Ver)")) | .files[] | select(.os == "linux" and .arch == "amd64" and .kind == "archive") | "filename=\"" + .filename + "\""')
[kir@kir-rhat runc]$ echo $PREFIX$filename
https://golang.org/dl/go1.20.3.linux-amd64.tar.gz
[kir@kir-rhat runc]$ GO_VERSION=1.19
[kir@kir-rhat runc]$ eval $(curl -fsSL "${PREFIX}?mode=json" | jq -r  --arg Ver "$GO_VERSION" '.[] | select(.version | startswith("go\($Ver)")) | .files[] | select(.os == "linux" and .arch == "amd64" and .kind == "archive") | "filename=\"" + .filename + "\""')
[kir@kir-rhat runc]$ echo $PREFIX$filename
https://golang.org/dl/go1.19.8.linux-amd64.tar.gz

[kolyshkin]

The bash and friends version was not that bad though...

-    SUFFIX=$(curl -fsSL "$PREFIX" | grep ' href="/dl/go'$GO_VERSION'.*linux-amd64\.tar\.gz"' | head -1 | sed -e 's#^.* href="/dl/\([^"]*\)".*$#\1#g')
-    curl -fsSL "$PREFIX$SUFFIX" | tar Cxz /usr/local
+    eval $(curl -fsSL "${PREFIX}?mode=json" | jq -r  --arg Ver "$GO_VERSION" '.[] | select(.version | startswith("go\($Ver)")) | .files[] | select(.os == "linux" and .arch == "amd64" and .kind == "archive") | "filename=\"" + .filename + "\""')
+    curl -fsSL "$PREFIX$filename" | tar Cxz /usr/local

but jq is the king as it's much more structured and thus bulletproof.

[thaJeztah]

found the docs! https://pkg.go.dev/golang.org/x/website/internal/dl

Ah! I was looking at the source code (spotted that @tianon added a link in that script). Was even considering if we could contribute a query-argument to filter the results by (major.minor) version. The code looks pretty straightforward, and I can envision such a query-parameter being useful for many purposes (including go-setup-action

[thaJeztah]

The bash and friends version was not that bad though...

Agreed! I was mostly concerned it the HTML output was stable enough, and JSON is more structured / stable in that respect.

[kolyshkin]

. Was even considering if we could contribute a query-argument to filter the results by (major.minor) version. The code looks pretty straightforward, and I can envision such a query-parameter being useful for many purposes (including go-setup-action

Yep, I'd rather use something like wget https://go.dev/dl/?version=1.20&os=linux&arch=amd64&kind=archive and be done with it.

Found a semi-relevant issue: golang/go#34864. Judging by it, it would be quite hard to move forward with a change like that.

[tianon]

Casually stealing that link and adding to the script so I can find it again later 😂 ❤️

[thaJeztah]

it would be quite hard to move forward with a change like that.

Yeah, generally most proposals would end up with "Based on the discussion above, this proposal seems like a likely decline"

But just looking at the code, it feels like adding additional filters wouldn't do much harm (and for sure wouldn't break backward compatibility); https://github.com/golang/website/blob/41e922072f17ab2826d9479338314c025602a3a1/internal/dl/server.go#L173-L183

[thaJeztah]

LGTM!

[kolyshkin]

Whoops, this one had the wrong label set. Fixed now.

[kolyshkin]

Backported to 1.1. in #3976.