<#490 RFC: Support Alpine> Issue created by <YOU54...
# pact-js-development
g
#490 RFC: Support Alpine Issue created by YOU54F Previous issues • pact-foundation/pact-js#1032 • pact-foundation/pact-js#1026 • pact-foundation/pact-js#899 (comment) Problem Alpine users are unable to utilise the
pact-js-core
and
pact-js
, since we switched to a Rust backed core powered by Pact FFI This causes inconvenience to both users, and maintainers, and friction in general for Pact adoption. It would be nice to provide at least preliminary support for Alpine with our Pact FFI. The Pact FFI library, since • 0.4.16 has published both x86_64 and aarch64 musl variants of the Pact FFI libary in static form
.a
• 0.4.17 has published converted
.so
musl variants Steps • Create Alpine based node prebuilds • We utilise
prebuildify
and native bindings, to be able to interact with our Pact FFI shared library. We pre-create these bindings in CI, so that our end-users do not need to build themselves (which requires Python/GCC and others) • Test Alpine based images in CI • We should test official Alpine node images, for the node versions we support Breaking Changes • Package size will be increased by ~90mb • ~45mb per musl arch (x86_64/aarch64) User Actions None Potential Downsides/Caveats ### Support levels We would probably consider this less supported than our existing glibc based versions, therefore we would probably want to ask that users recreate an issues encountered in Alpine, • Reproducible • Dockerfiles for any issue encountered, so a maintainer can reproduce • Add test to repo test suite • Add github repo, with CI, showing the issue • Alpine specific • Create the same example on a glibc based distro. The following would allow us to determine if it is a general Pact issue, or one specific to Alpine. I am unsure of how much we will be able to affect, that is Alpine specific, however we can compile a list of caveats/workarounds or bugs that appear out of them. Pact Plugins The Pact plugin ecosystem will not work properly on musl based systems until the following PR's are merged • pact-foundation/pact-plugins#56 • pact-foundation/pact-plugins#57 • pactflow/pact-protobuf-plugin#47 Without the above PR's, the pact-plugin drivers will attempt to download non musl variants of the plugins, which are unlikely to work on Alpine without glibc/gcompat. After the PR's are merged, the plugin-cli will attempt to download a musl variant, and fallback to the vanilla linux variant instead. Package sizes It may be the case that package sizes are too large, when installed on a target machine, as we store all the prebuilds in the published package. There are a few options we could take • Strip binaries • may cause issues • Don't package pre-builds in pact-js-core published package • Allow prebuildify to fetch required pre-build from GitHub releases • Allow user to specify path to their own prebuild (currently possible with PACT_PREBUILD_LOCATION) I know we used to download the standalone on the fly, back in older versions of pact-js/pact-node but this would cause issues in many corporate environments with proxies. Has it previously been tested Yes, but with modified musl variants of the plugin framework as per my above PR's • https://github.com/YOU54F/pact-js-core/tree/alpine • https://github.com/YOU54F/pact-js-core/actions/runs/7880984396/job/21503869458 The plugin tests are currently skipped on this repo, but were enabled in my testing, to try and test it out end to end. There were a few node based workarounds depending on the version used, and there is still an issue with some of the plugin tests on some variant combos against node 16. Other options • We do nothing • Users are unable to utilise Pact on Alpine, or have to use compatibility based workarounds which can result in weird behaviour • Users have to switch from using Alpine, to a glibc based distro. For some users/organisations, this isn't always easy, especially when trying to integrate Pact into an established ecosystem. pact-foundation/pact-js-core