github: Test with musl

[cole-miller]

MicroK8s and Juju consume dqlite as a static library build against musl libc, so let's test this in our CI to avoid unexpected breaks like #679.

Signed-off-by: Cole Miller [email protected]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.26%. Comparing base (494d6e7) to head (1fb3a1f).
Report is 25 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #682      +/-   ##
==========================================
+ Coverage   77.91%   81.26%   +3.34%     
==========================================
  Files         197      197              
  Lines       28011    29070    +1059     
  Branches     5536     4046    -1490     
==========================================
+ Hits        21826    23624    +1798     
+ Misses       4329     3832     -497     
+ Partials     1856     1614     -242     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cole-miller]

Running into this issue it seems: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764335.

[louiseschmidtgen]

Could you please include a test run against the musl tag used in our k8s distributions: https://github.com/canonical/k8s-dqlite/blob/master/hack/env.sh#L13? We might not always be on the same musl version as the juju team.

[SimonRichardson]

Juju will be happy to move to the later one, now we know the root cause. We intended to move that originally but ended up locating the segfault.

[cole-miller]

Sounds good.

[cole-miller]

I like how using a Dockerfile for this cleans things up. Looking into the segfaults.

[cole-miller]

This is ready. The new contrib/build-static.sh test script is derived from the one used by MicroK8s, and should be much more representative than building in an Alpine container.

The other changes in this PR are tweaks to the test suite to make it musl-friendly.

[letFunny]

Thanks Cole! Just a couple of comments and questions.

[letFunny]

I wonder if there is a way to define the test only for glibc without having to duplicate the rest of the file. The other problem is keeping the CI and the make recipes in sync when adding new tests/binaries.

I see that musl does not define a macro to detect it, but maybe there is a way:

• Either define a macro that gets passed when we want to enable the tests, gcc -D....
• Or identify glibc using __USE_GNU and use that to guard the tests.

We just have to #ifdef and skip the test early.

[cole-miller]

The other problem is keeping the CI and the make recipes in sync when adding new tests/binaries.

I'm on this, running subsets of tests seems to be poorly supported by Automake but we can have an environment variable that causes the addrinfo binary to return without running tests

We just have to #ifdef and skip the test early.

The problem is that any tests we want to run cannot be linked into the same binary as test_addrinfo.c because that file overrides getaddrinfo and it's impossible to avoid calling it. The only way to do it would be to effectively ifdef out all of test_addrinfo.c along with the tests that use it. If we went this route, rather than detecting glibc or musl I think it would be better to detect how libc is being linked since that's what makes the difference; we'd need to do some compiler flag sniffing or add a new option in configure.ac. I could go either way on this

[cole-miller]

I've reverted the commit that introduced the new test binary and switched to controlling this with a configure.ac option (that also causes -all-static to be passed) and conditional compilation. We can get away without duplicating or complicating the test source files, which is nice, and the tests show up in the output as skipped.

I also added a make target to print the list of test binaries so we don't have to copy the list anywhere.

[letFunny]

Thanks Cole! Just some comments about extra documentation. The code is looking very good and I like the solution a lot.