Update CI and build tools

[MrAlias]

As we move to a stable release of this project it would be ideal if we can assert confidence that this project will work on more than just linux systems with x86 or 386 CPU architecture. Additionally, it would be ideal if we could speed up the CI process.

1. Decouple the Makefile from a specific 386 CPU architecture run.
2. Add a testing matrix on the CI system to test different OS and architecture. We probably don't need to test all valid OS/arch pairs and can probably start with the following:
   • darwin/386
   • darwin/amd64
   • linux/386
   • linux/amd64
   • linux/arm
   • linux/arm64
   • windows/386
   • windows/amd64
3. The lint and other validation stages do not need to be run on each of these combinations of OS/arch, this stage of the build should be split out as a precursor to the build/test step.

I think a good example will be what the collector and collector-contrib has done:

• https://github.com/open-telemetry/opentelemetry-collector/tree/main/.github/workflows
• https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/.github/workflows

[lizthegrey]

please build linux/arm64 as well please, and I think we can drop linux/386

[MrAlias]

please build linux/arm64 as well please, and I think we can drop linux/386

Added to the list 👍

[MrAlias]

FWIW, I made the subjective selection on OS/arch from this list:

• aix/ppc64
• darwin/386
• darwin/amd64
• dragonfly/amd64
• freebsd/386
• freebsd/amd64
• freebsd/arm
• freebsd/arm64
• illumos/amd64
• js/wasm
• linux/386
• linux/amd64
• linux/arm
• linux/arm64
• linux/ppc64
• linux/ppc64le
• linux/mips
• linux/mipsle
• linux/mips64
• linux/mips64le
• linux/riscv64
• linux/s390x
• netbsd/386
• netbsd/amd64
• netbsd/arm
• netbsd/arm64
• openbsd/386
• openbsd/amd64
• openbsd/arm
• openbsd/arm64
• plan9/386
• plan9/amd64
• plan9/arm
• solaris/amd64
• windows/386
• windows/amd64
• windows/arm

[MrAlias]

Looking into testing arm or arm64 on the GitHub Actions platform I discovered that we will need to build and maintain our own runners. This does not sound like something we should invest in at this point.

I'm planning to keep trying to test the 386 architecture at this point to ensure we are testing a 32 bit architecture.

[rakyll]

Do we need 32-bit Windows and Mac? They are not that common anymore, especially in our target audience. I'd focus on the following initially:

• darwin/amd64
• linux/386
• linux/amd64
• linux/arm
• linux/arm64
• windows/amd64

[MrAlias]

Do we need 32-bit Windows and Mac? They are not that common anymore, especially in our target audience. I'd focus on the following initially:

• darwin/amd64
• linux/386
• linux/amd64
• linux/arm
• linux/arm64
• windows/amd64

We do not need to focus on the darwin/386 as that is indeed an invalid OS/ARCH pair. As for arm* from my previous comment, we are probably not going to be able to support testing these. At least not initially and in the long term we will need to decide if we want to manage a private runner.

[lizthegrey]

Do we need 32-bit Windows and Mac? They are not that common anymore, especially in our target audience. I'd focus on the following initially:

• darwin/amd64
• linux/386
• linux/amd64
• linux/arm
• linux/arm64
• windows/amd64

We do not need to focus on the darwin/386 as that is indeed an invalid OS/ARCH pair. As for arm* from my previous comment, we are probably not going to be able to support testing these. At least not initially and in the long term we will need to decide if we want to manage a private runner.

I'm okay with not running the tests, but we should still ensure that our example binaries compile with GOARCH, just to make sure no weird stuff slips in.

[jameshalsall]

Would running via https://github.com/marketplace/actions/arm-runner be an option?