Re: [musl] Current state and future of musl development infrastructure

[Natanael Copa <ncopa@alpinelinux.org>]

On Thu, 16 Dec 2021 00:02:20 -0500
Rich Felker <dalias@libc.org> wrote:

> On Wed, Dec 15, 2021 at 04:52:05PM -0600, Zach van Rijn wrote:
> > On Wed, 2021-12-15 at 22:22 +0100, jvoisin wrote:  
> > > Hello everyone,

...

> > As for CI.
> > 
> > It would probably be helpful to be able to run libc-test and
> > perhaps other applications on a number of real hardware platforms
> > in some automated manner.  
> 
> Yes. Having this automated would be really nice. Even better if it
> could be done not just for the official upstream repo but for proposed
> patches/patchsets or third-party git branches (on some sort of
> request).

I think it would be helpful to have the tests bundled in musl git
repository and in release tarballs. It is common practice for
downstream packagers to run `make && make check`, to run unit tests to
have some basic smoke testing (that does not require root permissions).

Depending on some external test suite (libc-test) is suboptimal because
they may not catch recent additions, and it may be difficult to keep
track of what is expected to pass or fail.

I think it would make sense to have both a lighter/faster integrated
set of unit tests, that are bundled with musl itself and have a more
extensive (external) integration tests that is run with the CI.

> I'd really love if the CI were optimized to do incremental builds and
> reuse artifacts as much as possible for rapid results, but doing that
> right probably requires fixing missing dependency tracking in the
> build.

Just an idea for incremental builds: Do out-of-tree builds. let the CI
store a tarball of the out-of-tree build in some key/value storage,
using the commit hash as the id. Subsequent builds tries fetch the old
heads community id from storage and extract it to the out-of-tree build
location.

It might also be a good idea to try get it work first and optimize
afterwards :)

-nc