Add 32-bit testing to CI

[SuperQ]

Run Go tests with 32-bit to validate value overflow.

[dswarbrick]

I can't really name a scenario off the top of my head where this would not be sufficient, but wouldn't it be more prudent to test 32-bit and 64-bit?

The Debian CI infrastructure builds and tests packages on all of their officially supported archs, including non-x86 stuff like ARM, PowerPC, MIPS, and s390x. I realise that CircleCI / GitHub Actions are substantially more limited in what they offer as platforms, so adding a test with GOARCH=386 is merely the least we can do, but I think that for the sake of completeness (and to rule out any weird side effects of testing solely in 32-bit, which probably gets less real-world exposure these days), tests should still be performed on the "native" arch, i.e. 64-bit.

[SuperQ]

This is testing both. the second make is a make all, which runs test. The second test is with GOARCH=amd64. So we're covered.

[SuperQ]

I would love to have a Prometheus pool over runners that test a bunch of archs. We had buildkite setup for the node_exporter running a bunch of QEMU VMs for various archs including ppc64, power, etc. But the lack of people to maintain the setup meant it eventually stopped working and we had to remove it from use.

But for the most part, testing a lot of archs with Go is nearly unnecessary. Except for these small 32-bit issues, Go just tends to work on everything. Except maybe Windows, we have tons of issues with Windows filesystem calls.

[dswarbrick]

I would love to have a Prometheus pool over runners that test a bunch of archs.

I think that testing at least additionally on ARM would be nice, due to the proliferation of Raspberry Pi devices. CircleCI supports ARM, but AFAIK the GitHub-hosted runners for GitHub Actions are still only x86. A privately-hosted runner would be an option perhaps.

But for the most part, testing a lot of archs with Go is nearly unnecessary.

True, although Debian's more thorough CI testing has also been instrumental in catching some quite corner-case issues in Prometheus in the past, such as inconsistent behaviour of atomic functions on MIPS (which seemingly turned out to be a Go toolchain issue), or floating point rounding differences on s390x related to FMA instruction support.

IMHO, if a binary is published for a specific platform, then it should also be tested on that platform. It should not just be assumed that we can blindly trust cross-compiled builds.

[SuperQ]

Yea, ARM is now much more possible with cloud providers providing ARM CPU nodes.

[sysadmind]

LGTM.

FWIW github actions seems to support different architectures through QEMU. Docker has actions to set this up to build cross architecture containers. https://docs.docker.com/build/ci/github-actions/multi-platform/