Re: [PATCH 4/5] travis-ci: don't run the test suite as root in the 32 bit Linux build

[Jeff King <peff@peff.net>]

On Mon, Jan 22, 2018 at 02:32:19PM +0100, SZEDER Gábor wrote:

> Travis CI runs the 32 bit Linux build job in a Docker container, where
> all commands are executed as root by default.  Therefore, ever since
> we added this build job in 88dedd5e7 (Travis: also test on 32-bit
> Linux, 2017-03-05), we have a bit of code to create a user in the
> container matching the ID of the host user and then to run the test
> suite as this user.  Matching the host user ID is important, because
> otherwise the host user would have no access to any files written by
> processes running in the container, notably the logs of failed tests
> couldn't be included in the build job's trace log.
> 
> Alas, this piece of code never worked, because it sets the variable
> holding the user name ($CI_USER) in a subshell, meaning it doesn't
> have any effect by the time we get to the point to actually use the
> variable to switch users with 'su'.  So all this time we were running
> the test suite as root.

This all makes sense to me, and the patch looks sane.

> Reorganize that piece of code in 'ci/run-linux32-build.sh' a bit to
> avoid that problematic subshell and to ensure that we switch to the
> right user.  Furthermore, make the script's optional host user ID
> option mandatory, so running the build accidentally as root will
> become harder when debugging locally.  If someone really wants to run
> the test suite as root, whatever the reasons might be, it'll still be
> possible to do so by explicitly passing '0' as host user ID.

Coincidentally, we recently set up a docker test build for our local fork
of Git. We found the whole "mount the existing git source tree" strategy
slightly annoying, exactly because of these mismatches between the host
and docker uids.

Instead, we ended up with something more like:

  git archive HEAD | docker run ...

and the in-container script starts with:

  tar -x

to extract the to-be-tested source, and ends with a dump of the failures
to stdout.

I don't know if it's worth switching strategies now, but just some food
for thought. It may be less interesting with Travis, too, because you're
also trying to carry the prove cache across runs, which does require
some filesystem interaction.

(As an aside, I'm not sure the prove cache is doing much. Running in
slow-to-fast order helps if you are trying to run massively in parallel,
but we only use -j3 for our Travis builds).

-Peff