You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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.
The text was updated successfully, but these errors were encountered:
Previous issues
Problem
Alpine users are unable to utilise the
pact-js-core
andpact-js
, since we switched to a Rust backed core powered by Pact FFIThis 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
.a
.so
musl variantsSteps
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)Breaking Changes
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,
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
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
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
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
The text was updated successfully, but these errors were encountered: