@contrast/crossbuilder v1.0.6

@contrast/crossbuilder

cli program to execute prebuildify in containers built from cross-compilation images. This is intended as a drop-in replacement for prebuildify-cross that simply passes the repository to the container as /input.

Usage

$ npm install @contrast/crossbuilder

$ npx @contrast/crossbuilder -i centos7-devtoolset7 -i alpine -t 16.9.1 -t 18.7.0

Like prebuildify-cross, the image name will be prefixed with ghcr.io/prebuild/ if it does not have a / in it and suffixed with :2 if it does not have a : in it. It also adds the option --tag-libc for centos and alpine images and --tag-armv for linux-arm and android-arm images.

This maps the container's stdout and stderr to the process' stdout and stderr so any errors will be visible.

Environment variables

• CI do not show image download progress
• NO_PROGRESS do not show image download progress
• KEEP_CONTAINER do not delete the container after successful execution

This also uses the debug package, so DEBUG=@contrast/crossbuilder will output some additional information.

Archeology

This is the second implementation of a prebuildify-cross replacement. The first used the docker-api directly. I discovered dockerode, an actively maintained repo, while looking into handling output, and dockerode simplified the implementation significantly.

The reason for replacing prebuildify-cross is that it just hangs (in wsl2 or github actions CI environments). I spent a lot of time trying to find out what is NOT happening that causes it to hang. Eventually, I decided it was easier to replace prebuildify-cross, docker-run, docker-remote-api, and the whole family of packages. They introduce multiple layers of complexity by passing the node program to execute via stdin and returning the artifacts built via stdout.

The only benefit to using stdin and stdout is that only a subset of files is made available to the container and the container does not require write access to the repo, with whatever permissions issues might arise from that. I don't believe that is an issue for our usage.

The primary change is that the repo to be built is mounted as '/input' in the container and the files are placed there, as they would be if docker were invoked interactively.