fix: Generated Assets suffix for CPU Architecture x64 is not correct

[Vad1mo]

The generated release assets contain a CPU architecture suffix x64 that is not usable (for automated processing)

Example:

• spectral-alpine-arm64
• /spectral-alpine-x64
• spectral-linux-arm64

In all cases, x64 is not a correct suffix for a CPU architecute. It can not be used to determine the right architecture.

Example for correct X86 64 bit architecture is AMD64

root@np2-4efec-bthtl:/# dpkg --print-architecture
amd64
root@np2-4efec-bthtl:/# uname -p
x86_64
root@np2-4efec-bthtl:/# lscpu
Architecture:            x86_64

ARM64 in M2

root@b4d451187ea2:/# dpkg --print-architecture
arm64
root@b4d451187ea2:/# uname -p
unknown
root@b4d451187ea2:/# lscpu | grep Architecture
Architecture:                       aarch64

Because in automation tools and workflows, often dpkg --print-architecture is used (see here) Example, Dockerfile

RUN curl -fsSL -o /usr/bin/spectral https://github.com/stoplightio/spectral/releases/download/$SPECTRAL_VERSION/spectral-linux-$(dpkg --print-architecture) && chmod +x /usr/bin/spectral

I suggest to generate the Assets with the amd64 for the x86 64 bit architecture.

[rainum]

Hi @Vad1mo,

First of all, thank you very much for your contribution to https://github.com/stoplightio/spectral/pull/2627. We appreciate any participation!

Hover, after doing some research, our team came to the following conclusions:

• In all cases, x64 is not a correct suffix for a CPU architecute. It can not be used to determine the right architecture.

  To be honest, we can't prove or disprove it. As far as we know architecture names are not standardized. Or we wasn't able to find any enumeration of the supported architectures by dpkg.

• That being said, we decided to resort to sticking to "common practices". And one of the most common packages is JS world nowadays is NodeJS itself. As you can see from the list of compiled binaries for a different architectures node team sticks to x64 variant: node-v22.2.0-linux-x64.tar.gz). To prove that it is compiled for the same architecture as a special binary, here is the result of running the file command for both binaries:

  $ file spectral-linux-x64
  spectral-linux-x64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=09cd36297a0e7652945b08ef82c63ce27a10e24b, for GNU/Linux 2.6.32, stripped
  
  $ file node-v22.2.0-linux-x64
  node-v22.2.0-linux-x64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=92ee19d9d9ba09d400f3568ec61cc76c683c4618, for GNU/Linux 3.2.0, with debug_info, not stripped, too many notes (256)

• Vercels' pkg package that we use for compiling binaries supports only x64 as target.
• And we are concerned, that changing the file name might break integrations that other people already have in place. Also, we see no value in duplicating the same binary with a different name.

To not leave you without any solution to your problem there are some good examples in the search list that you provided on how to add branching to your Dockerfile:

https://github.com/raveberry/raveberry/blob/7b7380599b55a9422dc71b9e427c0abefc6838e7/docker/dependencies.Dockerfile#L9-L17

Thanks for creating an issue along with the PR! Let us know if you have any questions.

[Vad1mo]

I see thank you for the detailed explanation.