Alpine/Musl with Pact Rust based core, in Pact client libraries

[YOU54F]

Status

Rust Libraries

library	alpine support	version
pact_ffi	✅	- x86_64 .a from 0.2.4
		- aarch64 .a from 0.4.15
		- .so from 0.4.17
pact_mock_server_cli	✅	- 1.0.5
pact_verifier_cli	✅	- 1.1.1
pact-stub-server	✅	- 0.6.0
pact-plugin-cli	✅	- 0.1.2
pact-protobuf-plugin	✅	- 0.3.15
pact-csv-plugin	✅	- 0.0.6

Note:- With exception to the pact_ffi library, the other libraries are provided as executables, statically linked to musl libc, which means they should work on all Linux distributions, both musl based (Alpine, Void, Chimera etc) & glibc based (Debian, RHEL etc)

Client Libraries

library	alpine support	version
pact-js	✅ PR	13.1.0
pact-php	✅ PR	10.0.0-beta1
pact-net	WIP PR
pact-go	WIP PR

Background

Many teams choose to run builds on Alpine Linux due to its tiny footprint, and smaller security surface area.

Guidance for Alpine users, has been stored on our docs site here

For Pact implementations that use the Ruby shared core

Support is available by installing glibc compatibility layers due the underlying runtime being built on centos7

https://github.com/pact-foundation/pact-ruby-standalone/wiki/Using-the-pact-ruby-standalone-with-Alpine-Linux-Docker

For Pact implementations that use the Rust shared core

Alpine or other musl based distros have not be supported due to

1. Lack of musl based artifacts from pact-rust based projects
2. Potential issues requiring the project to possibly be rebuilt against specific versions of Alpine / musl.

Point 1 is now addressed, partially for the FFI library.

Pact-Reference is now publishing musl based versions of the Pact-FFI as of 0.4.15

We would like to investigate creating musl variants of all the pact-reference (rust) based artifacts, and incorporating them into client libraries

Support Level

Any of the musl based artifacts should be considered somewhat experimental and you may encounter issues, as they have not been used for a long time. I would strongly advise these are not used in production workflows, unless you are handy and don't mind investigating issues yourself

We would gratefully ask that if issues are raised, that two things are provided

1. A minimal reproducible example of a Docker image/file based on Alpine that recreates the issue
2. A minimal reproducible example of a Docker image/file based on Debian that recreates the issue

Note - The debian image, may not show the same behaviour, this will be useful to determine where there are bugs/issues or gaps in the musl implementation which can be communicated to others.

How to participate?

Drop a comment in this thread, or reach out via slack in #libpact_ffi-users

FFI

Investigate the possibility of incorporating into client libraries

Pact-Js-Core

• Pact-Js-Core
  • build musl pact.node bindings - Delta
  • release prebuilds
  • CI Test runs
    • arm64 musl
    • amd64 musl

Snags

1. pact ruby standalone arm64 fail under qemu in GHA which fails test suite
2. some inconsistent behaviour in node 16 (set /tmp cache) / 18 ( max sockets 1)
3. prebuilds take a good while, but these could be limited to only running when the ffi, or native bindings are updated, or failing that just run on pull requests. regular test runs could just grab the latest pre build

Pact-JS

• Pact-JS

Pact-PHP

• Pact-PHP
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - gha
    • amd64 musl - gha

Snags

1. PHP can only load .so files, so requires converted .a musl library
2. AMD64 musl images require shared-mime-info installing for consistent content type matching, ARM64 doesn't. If installed, they flip behaviour.
3. Needs musl detection method in downloader/

Pact-Go

• Pact-Go
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - partially working, some seg faults
    • amd64 musl - partially working, some seg faults

Snags

1. Some seg fauls, also occur on vanilla x86_64 build although not consistently reproducible.

Pact-Net

• Pact-Net
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - gha - failing
    • amd64 musl - gha
    • arm64 musl - cirrus
    • amd64 musl - cirrus

Snags

1. .NET can only load .so files, so requires converted .a musl library
2. ARM64 musl on GHA fails to build project, but passes on Cirrus
3. Needs musl detection method in csproj file

add others

Mock Server CLI

• Create musl variants
  • Fork release
  • PR
  • Publish

Provider Verifier CLI

• Create musl variants
  • fork release
  • PR
  • Publish

Stub Server CLI

• Create musl variants
  • fork release
  • PR
  • Publish

Plugins

pact plugin cli

• fork release
• issue building existing x86_64 linux executable in CI (build with cross to retain known glibc version)
• pact plugin driver rust
• pact plugin driver jvm
• support downloading non musl variants if not avail, via pact-plugin-cli (rust and jvm driver)

Pact-Protobuf-Plugin

• Create musl variants
  • fork release
  • PR

Pact-csv-Plugin

• Create musl variants
• fork release
• PR

Pact-matt plugin

Build with goreleaser and linked with musl, so existing binaries work with alpine.

• support downloading non musl variants if not avail, via pact-plugin-cli (rust and jvm driver)

Client language FFI bindings that only support dynamic *.so libaries

For some languages, it is not possible to load a *.a static library.

• PHP
• Ruby
• Others?

It is possible however to convert a .a file to a .so file.

ar -x libpact_ffi.a
gcc -shared *.o -o libpact_ffi.so
rm -f *.o

This shrinks our .a file from 115mb to a circa 41mb .so file, which looks inline with the size of the musl node prebuild for pact-js

• Create .so musl variants of pact ffi
  • Fork release
  • Delta
  • PR
  • Publish

[YOU54F]

So that was a successful endeavour however, we are going to try a different approach.

The musl built artifacts with work on systems based on glibc, therefore we technically only need to build a single linux binary linked to musl.

This will reduce the need for determining glibc/musl for at least rust built executables.

It is still to be tested with the FFI, to determine if we can get away with just one set (musl based for all) We can't - we require independent ffi based linux artifacts for glibc and musl based targets

[YOU54F]

Only two left to go are pact-net and pact-go, with RFC's/PR's raised.

Will close this off