Stumbled across this and I'm not sure it's an issue though. The root cause is Intel vs ARM being handled differently on Linux, macOS and GOARCH.

• M1 Mac: uname -m: arm64
• Linux container on M1 Mac: docker run -it --rm alpine uname -m: aarch64
• Both Mac & Linux use x86_64 for Intel chips
• Go uses amd64 & arm64

Usually it's solved in scripts with something like:

case "$(uname -m)" in
    aarch64) arch=arm64 ;;
    x86_64) arch=amd64 ;;
esac

Stumbled across this and I'm not sure it's an issue though. The root cause is Intel vs ARM being handled differently on Linux, macOS and GOARCH.

• M1 Mac: uname -m: arm64
• Linux container on M1 Mac: docker run -it --rm alpine uname -m: aarch64
• Both Mac & Linux use x86_64 for Intel chips
• Go uses amd64 & arm64

Usually it's solved in scripts with something like:

case "$(uname -m)" in
    aarch64) arch=arm64 ;;
    x86_64) arch=amd64 ;;
esac

Yeh I agree that its generally easy to script your way out of this (and in fact maybe we should explicitly do this in the install script), however a bit of an issue could arise where this assumption was made in deeper layers where a build script just executes the uname -m without consideration. This too can be fixed however perhaps it might be simpler to centralise the fix by offering the binary (even if it is identical to arm64) since it should just be a copy of a release artifact. Could mean less work for the customer (even if small).