Release via Burrito+Nix

[rvolosatovs]

Feature or Problem

Closes #589 (no cross, no problem)
Closes #572
Closes #570

• No QEMU/Docker emulation used to build, only cross or native compilation
• Bakeware -> Burrito
• Builds for aarch64 and x86_64 glibc and musl toolchains
• Build caching
• Fully reproducible builds for everything except:
  • Mac NIFs
  • Windows NIF
• Link against GLIBC 2.29, which is compatible with Ubuntu 20.04 and later

Dependencies:

• MacOS: none
• Ubuntu:
  • ca-certificates - self-explanatory
• Alpine:
  • libgcc - that's actually a NIF dependency, which is added by the Rust compiler -crt-static on musl links with libgcc_s rust-lang/rust#82521
• Windows: none

After setting the required env variables the release can be reproduced via release within a nix shell (nix develop from anywhere within the repo or nix develop github:wasmcloud/wasmcloud-otp once the PR is merged)
There's also a make release target added in the root, which initializes a Nix shell and calls release

Note, that you have to first:

• build a Mac NIF for both architectures on a Mac and set appropriate env vars
• build a Windows NIF on a Windows box and set appropriate env vars
• set SECRET_KEY_BASE in your environment

Note, that NIFs can also be just fetched from one of CI runs

e.g. I have this in my .envrc (you may want to look into https://direnv.net/)

export SECRET_KEY_BASE="3ImiTAMO0TTD7wrACHrCA+ggkzpw6zGWvE3gtQwlXE6vmnDT9yGP5/WKpLWEJ8fF"
export HOSTCORE_WASMCLOUD_NATIVE_AARCH64_APPLE_DARWIN="path://$PWD/_nix/aarch64"
export HOSTCORE_WASMCLOUD_NATIVE_X86_64_APPLE_DARWIN="path://$PWD/_nix/x86_64"
export HOSTCORE_WASMCLOUD_NATIVE_X86_64_PC_WINDOWS_MSVC="path://$PWD/_nix/windows"

(you have to first fetch and unzip the libraries just like CI does, see workflow and error messages, if any)

Related Issues

Release Information

Consumer Impact

Testing

Built on platform(s)

• x86_64-linux
• aarch64-linux
• x86_64-darwin
• aarch64-darwin
• x86_64-windows

Tested on platform(s)

• x86_64-linux
• aarch64-linux
• x86_64-darwin
• aarch64-darwin
• x86_64-windows

Unit Test(s)

Acceptance or Integration

Manual Verification

[ricochet]

The x86 darwin error is interesting. Failed to load workspace members dependency.wasi-cap-std-sync was not found in workspace.dependencies

https://github.com/wasmCloud/wasmcloud-otp/actions/runs/4836354104/jobs/8619473766?pr=616#step:4:2319

[rvolosatovs]

The x86 darwin error is interesting. Failed to load workspace members dependency.wasi-cap-std-sync was not found in workspace.dependencies

https://github.com/wasmCloud/wasmcloud-otp/actions/runs/4836354104/jobs/8619473766?pr=616#step:4:2319

Yes, but it actually does not seem to influence the build, just a yet another preview2-prototyping oddity

[rvolosatovs]

See also #608 (comment)

[brooksmtownsend]

aarch64 is only compatible with Ubuntu 22.04 and later for now

@rvolosatovs is this required? I believe this will break the raspberry pi's running on debian:bullseye, which is the latest raspbian

Great callout for ca-certificates, which I'm sure is present in many Linux installations but we can explicitly call it out. I'll say that this worked for me on my Mac, and in a docker container, a previous test of Windows also worked great but i can give it another go as well.

[brooksmtownsend]

This is all fantastic work 🎉 As mentioned in the other comment I verified this works for mac/linux aarch64, will test x86 windows again after leaving this review.

I left a few nit comments, the one that we should probably address is using the -latest runners or pinned versions, I've opted for the pinned versions just to avoid our pipelines breaking out from under us when runners update, but it's not a hard-held stance

[brooksmtownsend]

This is all fantastic work 🎉 As mentioned in the other comment I verified this works for mac/linux aarch64, will test x86 windows again after leaving this review.

I left a few nit comments, the one that we should probably address is using the -latest runners or pinned versions, I've opted for the pinned versions just to avoid our pipelines breaking out from under us when runners update, but it's not a hard-held stance.

Edit: Windows works 🎉

[rvolosatovs]

aarch64 is only compatible with Ubuntu 22.04 and later for now

@rvolosatovs is this required? I believe this will break the raspberry pi's running on debian:bullseye, which is the latest raspbian

Should be done now, please test both GNU builds once CI finishes

[brooksmtownsend]

LGTM once tests pass, works for me on aarch64 linux, mac, and x86 windows

[brooksmtownsend]

LGTM once tests pass, works for me on aarch64 linux, mac, and x86 windows

[rvolosatovs]

LGTM once tests pass, works for me on aarch64 linux, mac, and x86 windows

Could you try to restart them? (Potentially a few times) Since I have not changed the implementation, it appears as a flake to me.

Otherwise, could you tell me what is there to be fixed? There are way too many logs and it's impossible to figure out what's wrong for someone unfamiliar with the project (like myself)