Build aarch64-unknown-linux-musl and add to Go package

[connec]

Hi,

This builds on #1535 to add a build job for aarch64-unknown-linux-musl, which is added to the library artifacts as libpolar-Linux-arm.a. I've only propagated this to the Go package as it's relevant to my use-case.

Unfortunately, it's not quite there yet – the built artifact works fine if I use it in an alpine-based container on an m1 mac, but when running it in an ubuntu-based container on an m1 mac I get spooky FFI errors that I'm unsure how to debug: https://github.com/connec/oso/runs/5478560216?check_suite_focus=true

I suspect I'm missing some particular incantation of RUSTFLAGS and/or cgo... The errors typically seem to relate to malloc, so I'm guessing it's perhaps something like it's using glibc's in Go and musl's in Rust, or something like that? I'm not sure why this one struggles when the x86 MUSL version seems to "just work" on ubuntu-latest. Perhaps someone with more FFI experience will spot something obvious.

⚠️ Depends on #1535.

---

Commits: (excluding the first 2 since they're part of #1535)

• 4db2c3c Make build cache depend on target rather than OS

  This should lead to less churn in the cached artifacts.

• ebc26d9 Add a static library build for ARM Linux (musl)

• b7fa218 Fix path creation in build_go

  Since they already existed this went unnoticed.

• 5de3c5a Prepare Go package for Linux ARM

  This introduces the architecture indirection for AMD64, in the same
  style as aleady exists for MacOS.

• b1cc808 Add Linux ARM64 support to Go package

  This requires a Linux ARM64 runner to validate the package, which can
  most easily be achieved by running a container on an m1 mac.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[connec]

For reference, I've been testing the build with a runner in an ubuntu container on an m1 mac, built with the following Dockerfile.

Dockerfile

FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
  build-essential \
  curl \
  libdigest-sha-perl \
  && rm -rf /var/lib/apt/lists/* \
  && curl -o go1.17.8.linux-arm64.tar.gz -L https://go.dev/dl/go1.17.8.linux-arm64.tar.gz \
  && tar -C /usr/local -xzf go1.17.8.linux-arm64.tar.gz

RUN groupadd -r runner && useradd --no-log-init -r -m -g runner runner

USER runner
WORKDIR /actions-runner
RUN \
  curl -o actions-runner-linux-arm64-2.288.1.tar.gz -L https://github.com/actions/runner/releases/download/v2.288.1/actions-runner-linux-arm64-2.288.1.tar.gz \
  && echo "9fbb98fc64f57d48e86b641bd3dd54d870123afc32886b5ca1c33bdc10afb6ee  actions-runner-linux-arm64-2.288.1.tar.gz" | shasum -a 256 -c \
  && tar xzf ./actions-runner-linux-arm64-2.288.1.tar.gz \
  && /usr/local/go/bin/go install golang.org/dl/go1.16@latest && ~/go/bin/go1.16 download \
  && /usr/local/go/bin/go install golang.org/dl/go1.17@latest && ~/go/bin/go1.17 download

USER root
RUN DEBIAN_FRONTEND=noninteractive ./bin/installdependencies.sh

USER runner
RUN echo './config.sh --url "https://github.com/$RUNNER_REPO" --token "$RUNNER_TOKEN" --name "$RUNNER_NAME" && ./run.sh' > config-and-run.sh

ENV RUNNER_REPO=osohq/oso
CMD ["/bin/bash", "config-and-run.sh"]

You can run the built image with, e.g. docker run --env RUNNER_TOKEN='...' --env RUNNER_NAME=whatever.

[patrickod]

hey @connec

thank you for this and #1535 and also for your patience.

RE: changing the build workflow to use a matrix. We actually used this pattern previously and found that the performance was poorer than expected. While in theory breaking out each job should allow us to chew through them much faster, in practice grouping by target as we have done here ends up being quicker. We would definitely love to add aarch64 linux targets to the mix, and I think the changes here could be easily appended to the build_linux_libs task

RE: shipping this Go aarch64. We very much hope to support aarch64, the primary issue is that we currently lack an ARM64 test environment to validate these builds properly. We have some plans to establish some ARM64 linux build and test action environments, but until then we've opted to hold back on this work. We're conscious that with growing popularity and availability of ARM targets that we'll need to revisit this in the near future, however I unfortunately can't offer a strict timeline on when this will be shipped as we are currently heads down as a team on a complimentary product sprint.

[connec]

No problem. I'll close this then as it's not suitable in its current form, and blocked as you say.