This is the mail archive of the
mailing list for the glibc project.
RFC [0/2] test-in-container
- From: DJ Delorie <dj at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Thu, 08 Feb 2018 18:01:54 -0500
- Subject: RFC [0/2] test-in-container
- Authentication-results: sourceware.org; auth=none
With this patch set, I'm introducing a way to test parts of libc that
are difficult (if not impossible) to test "in the build directory".
For example, verifying that the correct configuration file is loaded,
or testing search paths, etc. To do this, a new class of tests is
defined which are tested in a container which is configured as a
mini-chroot. This container has its own namespace so many root-like
functions work, allowing user-level but root-priviledged testing.
I'm currently asking for design feedback, not the usual comprehensive
review prior to committing.
The first patch [1/2] contains the infrastructure, mostly in
support/test-container.c which maintains the test-specific container
and manages the containerization.
The second patch [2/2] shows how to migrate a test to this system, by
The overall flow of the container system is:
* Once per "make check" we do a "make install" into
$builddir/testroot.pristine. This is only redone if needed, but 'if
needed' is loosely defined at the moment.
* Once per test, we rsync the pristine root to the working root. Then
we do some pre-test setup, run the test, and do post-test cleanup.
The idea here is to minimize the overhead of providing an installed
root that might be "corrupted" by the test (the test might be testing
for missing files, bad modes, corrupted files, etc).
For obvious reasons, the tests cannot be run in-container in-parallel.
A simple serialization is provided, but it means that a future "run
everything in a container" would need a redesign for multi-threaded
This system is also incompatible with ssh-based cross-testing, if only
because test-container.c is compiled with the native tools and I
didn't want to make this patch more complex than needed.
For each test, the "pre-test setup" involves copying a per-test root
template and/or running a per-test "script" that knows how to copy
files into the chroot, change permissions, delete files, and rename
files. There's a big comment in test-container.c that documents all