Support Windows, aarch64 with our Distillery Release

[brooksmtownsend]

Finished items

• [x] Automation of creating the wasmcloud_host-v0.20.0-x86_64-linux-gnu.tar.gz artifact
• [x] Automation of creating and pushing the wasmcloud_host:0.20.0 Docker image (hosted on wasmcloud.azurecr.io and docker.io)
• [x] Automation of creating the wasmcloud_host-v0.20.0-x86_64-macos.tar.gz artifact using macos github runner

Need to be done

• [x] Automate the creation of release with a pushed tag that includes the above artifacts
• [x] Automation of creating the wasmcloud_host-v0.20.0-x86_64-windows.tar.gz artifact
• [ ] Automation of creating the wasmcloud_host-v0.20.0-aarch64-linux-gnu.tar.gz artifact

Optional / Post MVP

• [ ] Automation of creating the wasmcloud_host-v0.20.0-aarch64-macos.tar.gz artifact

@billyoung I'd be happy to pull up for a quick chat to go over the work that I've done, but the TL;DR is that the elixir runtime is packaged with a distillery release. This creates a standalone .tar.gz which can be unzipped and then ran using ./install_dir/wasmcloud_host foreground or ./install_dir/wasmcloud_host start. This, by itself, is an awesome system, but there are 2 parts that make it difficult.

1. The elixir runtime system (ERTS) is bundled with the application by default. This is compiled for an operating system/architecture, so it has to match. We have the option to not include the elixir runtime, but if we do that then the user must install the exact same version of elixir and erlang that we built it with or the project will fail to run.
2. We use Native Implemented Functions (NIFs) to bring in some of our Rust functionality as callable C functions. These must be compiled for an OS/ARCH, so even if we don't bundle the ERTS the NIFs will still have to match the host machine.

In order to tackle this, my first approach was to create a generic docker image where I used a different image for building the elixir runtime, rust NIFs, and for the distributed docker image I just copied and ran the application with a basic image (I used debian:buster-slim). This worked great for x86 linux, but started to fall apart for different architectures and OSes due to the complexity of cross compiling elixir and Rust, and no generally available docker images for MacOS. I still use this Dockerfile and the Dockerfile.release for the x86 linux build because it's efficient and creates our docker image for us, and I think it's generic enough that it could be used for aarch64 linux and maybe even Windows if you know how to set it up (I couldn't).

With the difficulty of macos and windows and cross compilation builds, I decided to go with using the github macos / windows runner for the next part. The current state of this effort is I have most of the macos build scaffolded out, just dealing with caching the erlang installation so we don't spend 30 minutes installing it every time. Once I finish that up, I'd love to handoff to you (Bill) to help drive this effort home!

[stevelr]

we want a way to manually produce a tarball for a particular arch

[brooksmtownsend]

we want a way to manually produce a tarball for a particular arch

In order to do this, we can likely temporarily duplicate the release action and set the trigger to be manual, rather than triggered from a release. We'll also need to ensure that the artifact (tarball) is attached to the action, and that the docker image is not automatically published to the repository we intend to use for our official images

Edit: this is done in #188

[thomastaylor312]

I'm working on the windows side of things

[brooksmtownsend]

No longer applicable, we use mix releases! 🚀