Add support for Apple Silicon

[phamann]

We currently don't produce a target binary for apple silicon (i.e. arm64).

This should hopefully be a simple addition to the CI pipline matrix. However the current worflow in the CI pipeline makes certain assumptions that macOS is a single architecture, and therefore may need somne light refactoring.

[zakariamofaddel]

Hey Patrick😁
I've had issues with the @fastly/js-compute npm package, where there is a js-compute-runtime-cli.js file that checks the current platform the CLI is running on.
When running the cli commands on an M1 system everything works great, because you can see the Darwin version is included in this map in that file:

...

function getPlatform() {
  const osMap = {
    Windows_NT: {
      name: "windows",
      archs: {
        x64: "x86_64",
      },
    },
    Linux: {
      name: "linux",
      archs: {
        x64: "x86_64",
      },
    },
    Darwin: {
      name: "macos",
      archs: {
        arm64: "x86_64",
        x64: "x86_64",
      },
    },
  };
...

But when installing the cli on a debian based docker container running on the same M1 machine, I face an error, because osMap.Linux.archs is missing arm64

Is this related to this issue you opened? Is there a temporary solution for that or is there anything planned for it?

[JakeChampion]

We currently don't produce a target binary for apple silicon (i.e. arm64).

This should hopefully be a simple addition to the CI pipline matrix. However the current worflow in the CI pipeline makes certain assumptions that macOS is a single architecture, and therefore may need somne light refactoring.

It looks like GitHub does not yet support arm64 hosted runners:
actions/runner-images#2187 (comment)
actions/runner-images#2552
If we wanted to add support for this by updating the matrix then we would need to create some arm64 machines to use as self-hosted GitHub runners.

There might be a way to do this without having to run on arm64 ourselves but I don't yet know how that would look

[JakeChampion]

This was resolved when we rewrote the rust cli to JavaScript in version v0.5.7 🥳