@contrast/crossbuilder
v1.0.6
Published
execute prebuildify in multiple images
Downloads
53
Maintainers
Keywords
Readme
@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 progressNO_PROGRESS
do not show image download progressKEEP_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.