add `go test std` to image tests

[tianon]

It's probably a bit much to add directly in the image build (and might have side effects, like writing logs or temporary files that we don't want), but it would be very reasonable and very prudent for us to add a test of all our images that explicitly runs go test std to run all the standard library tests (especially for images like #464 / #531 👀).

[tianon]

We'll also need to be careful/mindful of Alpine; see golang/go#19938

[tianon]

$ time docker run -it --rm --dns 8.8.8.8 --init golang:1.24 go test std
...

real	7m27.549s
user	0m0.019s
sys	0m0.019s
$ nproc
16

So it'll probably take a lot longer on GHA servers, but that's just a good reason for it to be an image test, not something during build. 👍

[tianon]

We'll also need to be careful/mindful of Alpine; see golang/go#19938

Oh snap, docker run -it --rm --init --dns 8.8.8.8 --cap-add NET_ADMIN golang:1.24-alpine sh -c 'apk add --no-cache gcc libc-dev iproute2-minimal && exec "$@"' -- go test std passes all the tests too. 👀

[tianon]

Oh, we should include cmd too, apparently (go test std cmd), but even better would be to run go tool dist test (with the added complexity that go tool dist isn't built by default): https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/cmd/dist/test.go;l=658

go run cmd/dist test seems to do the trick, though 👀

[tianon]

For some reason, dist requires GOROOT to be set explicitly, but that's a really easy fix. Here's successful versions of both Linux variants:

$ nproc # yes, I switched to an even beefier machine because Go is really good at maxing it out and thus being a lot faster 🙈
32

$ time docker run -it --rm golang:1.24 sh -c 'GOROOT="$(go env GOROOT)" && export GOROOT && exec "$@"' -- go run cmd/dist test

##### Test execution environment.
# GOARCH: amd64
# CPU: Intel(R) Core(TM) i9-14900K
# GOOS: linux
# OS Version: Linux 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64

##### Testing packages.
ok  	archive/tar	0.076s
...

ALL TESTS PASSED

real	1m45.872s
user	0m0.013s
sys	0m0.021s

$ time docker run -it --rm --init --dns 8.8.8.8 --cap-add NET_ADMIN golang:1.24-alpine sh -c 'apk add --no-cache gcc libc-dev iproute2-minimal && exec "$@"' -- sh -c 'GOROOT="$(go env GOROOT)" && export GOROOT && exec "$@"' -- go run cmd/dist test
fetch https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.21/community/x86_64/APKINDEX.tar.gz
(1/18) Upgrading musl (1.2.5-r8 -> 1.2.5-r9)
(2/18) Installing libgcc (14.2.0-r4)
(3/18) Installing jansson (2.14-r4)
(4/18) Installing libstdc++ (14.2.0-r4)
(5/18) Installing zstd-libs (1.5.6-r2)
(6/18) Installing binutils (2.43.1-r1)
(7/18) Installing libgomp (14.2.0-r4)
(8/18) Installing libatomic (14.2.0-r4)
(9/18) Installing gmp (6.3.0-r2)
(10/18) Installing isl26 (0.26-r1)
(11/18) Installing mpfr4 (4.2.1-r0)
(12/18) Installing mpc1 (1.3.1-r1)
(13/18) Installing gcc (14.2.0-r4)
(14/18) Installing libcap2 (2.71-r0)
(15/18) Installing libelf (0.191-r0)
(16/18) Installing libmnl (1.0.5-r2)
(17/18) Installing iproute2-minimal (6.11.0-r0)
(18/18) Installing musl-dev (1.2.5-r9)
Executing busybox-1.37.0-r9.trigger
OK: 172 MiB in 33 packages

##### Test execution environment.
# GOARCH: amd64
# CPU: Intel(R) Core(TM) i9-14900K
# GOOS: linux
# OS Version: Linux 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64

##### Testing packages.
ok  	archive/tar	0.048s
...

ALL TESTS PASSED

real	1m47.948s
user	0m0.009s
sys	0m0.009s

[tianon]

Somewhat ironically, my tests of our Windows images show that our Nano Server images are closer to passing than Server Core, probably because they skip Git-related tests due to a lack of Git in the image, where Server Core tries to run those tests and fails for reasons that are likely related to our usage of "MinGit" instead of "full" Git (but Nano Server also fails in several places because it tries to shell out to powershell 😂 😭).

[tianon]

With a bunch of finagling, I got Windows Server Core down to just complaining about gcc for cgo-related tests, but trying to resolve that is a whole new can of worms that lights me back up like it's Christmas in February, so uh, I might need to stop going down this rabbit hole for now.

[tianon]

It's a hack, but just to document it for the future, this gets really close with Server Core (Nano is going to be harder because of the powershell thing, I think):

FROM golang:1.24

RUN Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

RUN rm -r /git
RUN choco install --yes git
RUN git --version

RUN tzutil /s UTC

#RUN choco install --yes mingw
#RUN gcc --version

To be clear, I wouldn't do it anything like this (curl | bash Invoke-WebRequest | powershell) for the real deal, but this is what I've been messing with to make progress and figure out what's necessary.