add ci job to pre-build osx and Linux multi-arch

[geekgonecrazy]

Closes #3

I have a failing job included for musl - needed to compile on alpine.

I'm going to keep battling a bit.. might be a lost cause.

But this will compile both x64 and arm64 for osx as well as i686 and x64 for linux and given credentials can ship to npm registry automatically.

Example of the CI running: https://github.com/geekgonecrazy/matrix-rust-sdk-bindings/actions/runs/2222780302

[geekgonecrazy]

https://github.com/geekgonecrazy/matrix-rust-sdk-bindings/actions/runs/2229035529 alright shouldn't need to mess with it any more. Here is an example of it finishing to publish.

We temporarily created a fork copy of the npm packages which can be found in the PR that referred above.

[turt2live]

Overall this is really great to see. It was always the intention to add more prebuilds, though doing so completely with CI is a bit interesting.

This would be our first project to publish directly from GHA, so there's extra concern which goes into this. The original intent of the build pipeline we've made is to allow a developer on a release machine run yarn publish and it'll take care of the pre-builds and such, so environmental dependencies are entirely valid.

It's true though that without prebuilds we end up in a case where downstream developers need the same pipeline, which isn't great. The plan was to provide prebuilds for Mac, Windows, and Linux before pushing this library out widely :)

I'll have our team look into safely using the npm token, but in the meantime if you have resources for how people manage npm releases managed by a CI pipeline it'd be appreciated. Of concern would be the awkward dance for git tagging: yarn publish currently does a lot of the heavy lifting for us, including picking a new version number, but we'd lose that automation as part of requiring a CI pipeline.

[geekgonecrazy]

Sorry for the delayed response here.

Your approach sounds exactly like what my initial thought was. Having prebuilts available even remotely that is fetched during packaging would to me work just fine. I just went the route of trying to automate end to end because seemed the quickest for me. Little did I know the trouble I would run into just getting some of the builds to even be reproducible consistently in a CI 🙈

---

As to the using the CI. To me I like this approach because makes the builds repeatable and no one has to worry about getting things just right on a bunch of machines and then combining them manually together for a release.

We do utilize github CI a lot in Rocket.Chat and have it publish to docker, npm, snap store etc. So we've put a good bit of trust in it. But we feel it's important to be able to automate these sort of things.

---

Some notes about this PR. Since this PR.. The alpine build does not work. While it compiles and everything seems great.. when trying to load on alpine it depends on a memcpy that is not in the musl glibc compatibilty package. So it might should be excluded from this build.

I've spent many hours banging my head against the wall for it. Tried building on alpine, introducing newer versions of glibc compat compiled from source for alpine... Also tried different compile time options to try and make use musl-cc instead of gcc or musl-gcc (apparently now days its just musl-gcc).

For ubuntu / centos etc.. it seems that need to target an older version of glibc... as does work on newest ubuntu it does not work on 16.04 and centos at all.

It's possible that targeting an older version of glibc would use an instruction set that is in the musl compatibilty layer.

The problem with that so far is that in trying to automate that I tried on Ubuntu 16.04 but it then needs a newer version of CMake for rust to be able to compile in parallel. So I kind of gave up for now on that.

---

So in summary its' definitely missing the bow tied on top. Feel free to take what you will here. The mac builds seem to work great so far so at very least that seems to be a good addition.

[gnunicorn]

Our action plan is release a complete rewrite of the nodejs-bindings based on the latest crypto-ffi crates, using vodozemac. So in that case we wouldn't need CMAKE and all that stuff anymore but it would only built using rust. Would that alleviate your build pains, @geekgonecrazy ?

ref matrix-org/matrix-rust-sdk#699

[geekgonecrazy]

I haven't fully understood what all of the plan means yet. Based on what I heard in the matrix live podcast. It sounds like the plan is to rely more heavily on it. And wasm is at play? I haven't really ever used wasm with node. Not sure if arch specific builds are needed? I kind of assume so.

If its still loading native code still it will probably still going to need to have prebuilt for each platform and architecture right? So I don't think it would actually fix the main problem.

The main problem is when the package is installed that computer has to have the whole rust toolchain just to be able to install the module. Which for normal devs and server admins they don't have this preinstalled.

The normal flow for these devs and end users is:

1. Download the release bundle
2. npm install
3. run

If we don't ship pre-built then the flow becomes

1. Download release bundle
2. npm install
3. it fails..
4. go find an issue or communication somewhere explaining what I have to do
5. have difficulties installing for chosen platform or distro (because lets face it this is just what happens)
6. Hopefully then run it and it work

[poljar]

So the thing is that we can't in good conscience let CI take over the release process of such a security critical component.

The plan is to eventually provide pre-built binaries for a bunch of bindings for the matrix-sdk-crypto crate, but we don't have yet the infrastructure set up.

In the meantime, the build has been simplified since it includes only Rust code nowadays. cargo build should just work for compilation as well as for cross-compilation.

I do see wasm mentioned there. I'm not sure if that means that the need for platform specific builds goes away?

It does if you're in browser land, the storage implementation for WASM uses IndexedDB, Node bindings are likely still wanted, to get the performance gains of a native executable, and to avoid having to mess around with IndexedDB shims for node.

[geekgonecrazy]

So the thing is that we can't in good conscience let CI take over the release process of such a security critical component.

I mean end of the day this is y'all's choice as the maintainers. If it makes sense for y'all to maintain infrastructure and manually build things instead of letting a CI build. That's definitely your choice.

As long as the releases end up being made with the prebuilts included for all the other platforms. Our project and end users will be happy.

Either way Looking forward to when the builds are pure rust and can successfully crosscompile. Keeping an eye on that development.

I'll go ahead and close this PR out