Unsupported versions cause GH Actions failures

[Jeffrey Esquivel S.]

Hi!

I was investigating the reason why the CI is failing and I found a couple of main causes:

1. The MacOS job is failing because the optional chaining operator used by a dependency is not supported on Node v12.
2. The Linux jobs are failing because the runner image for Ubuntu 18.04 has been removed from GHA.

Updating to a new version works (with just a few minor changes to the workflow and binding.gyp) except for one thing: there is no way to install a version of g++ that is compatible with c++17 (needed for compiling the native addon for newer Node versions) on a manylinux_2_24 container since it's based on Debian 9. Upgrading to manylinux_2_28 won't help because it is based on AlmaLinux and cross-compiling to ARM is not as straightforward as it was with the previous image.

From here, there are a couple of different strategies I could think of to solve this:

• Keep the fix as "least invasive" as possible by moving from manylinux_2_24_x86_64 to node:14-buster, which is Debian based and has the advantage of already including Node and NPM in the container image itself.

• Refactor the current GHA workflow into one workflow for building and one for testing while taking advantage of different tools (prebuildify-cross instead of manylinux) and supporting new platforms (windows).

Please advise me on which option would be preferable (if any) to the project maintainers to submit a PR.

Thanks!

[Kris Zyp]

The MacOS job is failing becase ... Node v12

We can remove v12, Node v12 is not even supported by Node itself.

Keep the fix as "least invasive" as possible by moving from manylinux_2_24_x86_64 to node:14-buster

Last I checked, I think node:14-buster didn't have python 3, so it can't do prerequisite binary compilation.

Refactor the current GHA workflow into one workflow for building and one for testing while taking advantage of different tools (prebuildify-cross)

You could try this, but I think I have tried this, and I don't think it works very well. For one, I don't think it has the older glibc compatibility of manylinux.

I think it is probably easiest to just copy the build scripts/config from the much more up-to-date lmdb-js repo https://github.com/kriszyp/lmdb-js/blob/master/.github/workflows/prebuild.yml, which has been pretty extensively tested.

[Jeffrey Esquivel S.]

Hi!

Last I checked, I think node:14-buster didn't have python 3, so it can't do prerequisite binary compilation.

I think they probably added it at some point more recently:

$ docker run -it --rm node:14-buster /bin/bash
root@7f94d3bdc61f:/# python3 --version
Python 3.7.3

Refactor the current GHA workflow into one workflow for building and one for testing while taking advantage of different tools (prebuildify-cross)

You could try this, but I think I have tried this, and I don't think it works very well. For one, I don't think it has the older glibc compatibility of manylinux.

My ideas was to use prebuildify-cross to compile the linux-x64 addons on their centos7-devtoolset7 docker image to maintain the same level of compatibility as manylinux2014_x86_64 (which is also based on CentOS 7).

I think it is probably easiest to just copy the build scripts/config from the much more up-to-date lmdb-js repo https://github.com/kriszyp/lmdb-js/blob/master/.github/workflows/prebuild.yml, which has been pretty extensively tested.

Well, the easiest for me would be to go with one of the approaches I mentioned earlier because I already have working branches for them (I wanted to understand how everything worked before suggesting possible solutions here 😅 ). You can check the branches, the results of running them on GH Actions and the final uploaded binary addons.

But I also see the value of using a solution that has already been well tested and that also provides consistency across projects (which is easier to maintain in the future). So if you prefer this option, I can got this route and make a PR based on that.

[Kris Zyp]

I think I will try using your prebuildify-cross solution for node-lmdb, and maybe I will try your suggested containers for lmdb-js (where I am using multi-package binaries that I don't think prebuildify-cross supports.

[Jeffrey Esquivel S.]

Great! Let me know if you want any help when trying this solution out on lmdb-js, I'd be happy to help.

I'm closing this issues as it's already solved.

[Kris Zyp]

Just published (v0.10.0) if you want to check it out.

[Jeffrey Esquivel S.]

It worked perfectly. Thank you!