The 32 bit Linux build job runs in a Docker container, which lends
itself to running and debugging locally, too. Especially during
debugging one usually doesn't want to start with a fresh container
every time, to save time spent on installing a bunch of dependencies.
However, that doesn't work quite smootly, because the script running
in the container always creates a new user, which then must be removed
every time before subsequent executions, or the build script fails.
Make this process more convenient and don't try to create that user if
it already exists and has the right user ID in the container, so
developers don't have to bother with running a 'userdel' each time
before they run the build script.
The build job on Travis CI always starts with a fresh Docker
container, so this change doesn't make a difference there.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
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.
Finally, one last catch: since commit 7e72cfcee (travis-ci: save prove
state for the 32 bit Linux build, 2017-12-27) the 'prove' test harness
has been writing its state to the Travis CI cache directory from
within the Docker container while running as root. After this patch
'prove' will run as a regular user, so in future build jobs it won't
be able overwrite a previously written, still root-owned state file,
resulting in build job failures. To resolve this we should manually
delete caches containing such root-owned files, but that would be a
hassle. Instead, work this around by changing the owner of the whole
contents of the cache directory to the host user ID.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some of our 'ci/*' scripts repeat the name or full path of the Travis
CI cache directory, and the following patches will add new places
using that path.
Use a variable to refer to the path of the cache directory instead, so
it's hard-coded only in a single place.
Pay extra attention to the 32 bit Linux build: it runs in a Docker
container, so pass the path of the cache directory from the host to
the container in an environment variable. Note that an environment
variable passed this way is exported inside the container, therefore
its value is directly available in the 'su' snippet even though that
snippet is single quoted. Furthermore, use the variable in the
container only if it's been assigned a non-empty value, to prevent
errors when someone is running or debugging the Docker build locally,
because in that case the variable won't be set as there won't be any
Travis CI cache.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The script 'ci/run-linux32-build.sh' running inside the Docker
container of the 32 bit Linux build job uses an && chain to break the
build if one of the commands fails. This is problematic for two
reasons:
- The && chain is broken, because there is this in the middle:
test -z $HOST_UID || (CI_USER="ci" && useradd -u $HOST_UID $CI_USER) &&
Luckily it is broken in a way that it didn't lead to false
successes. If installing dependencies fails, then the rest of the
first && chain is skipped and execution resumes after the ||
operator. At that point $HOST_UID is still unset, causing
'useradd' to error out with "invalid user ID 'ci'", which in turn
causes the second && chain to abort the script and thus break the
build.
- All other 'ci/*' scripts use 'set -e' to break the build if one of
the commands fails. This inconsistency among these scripts is
asking for trouble: I forgot about the && chain more than once
while working on this patch series.
Enable 'set -e' for the whole script and for the commands executed
under 'su' as well.
While touching every line in the 'su' command block anyway, change
their indentation to use a tab instead of spaces.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change follows suit of 6272ed319 (travis-ci: run previously
failed tests first, then slowest to fastest, 2016-01-26), which did
this for the Linux and OSX build jobs. Travis CI build jobs run the
tests parallel, which is sligtly faster when tests are run in slowest
to fastest order, shortening the overall runtime of this build job by
about a minute / 10%.
Note, that the 32 bit Linux build job runs the tests suite in a Docker
container and we have to share the Travis CI cache directory with the
container as a second volume. Otherwise we couldn't use a symlink
pointing to the prove state file in the cache directory, because
that's outside of the directory hierarchy accessible from within the
container.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The change in commit 4f2636667 (travis-ci: use 'set -x' in 'ci/*'
scripts for extra tracing output, 2017-12-12) left a couple of rough
edges:
- 'ci/run-linux32-build.sh' is executed in a Docker container and
therefore doesn't source 'ci/lib-travisci.sh', which would enable
tracing executed commands. Enable 'set -x' in this script, too.
- 'ci/print-test-failures.sh' iterates over all the files containing
the exit codes of all the executed test scripts. Since there are
over 800 such files, the loop produces way too much noise with
tracing executed commands enabled, so disable 'set -x' for this
script.
- 'ci/run-windows-build.sh' busily waits in a loop for the result of
the Windows build, producing too much noise with tracing executed
commands enabled as well. Disable 'set -x' for the duration of
that loop.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When Git v2.9.1 was released, it had a bug that showed only on Windows
and on 32-bit systems: our assumption that `unsigned long` can hold
64-bit values turned out to be wrong.
This could have been caught earlier if we had a Continuous Testing
set up that includes a build and test run on 32-bit Linux.
Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SZEDER Gábor
Johannes Schindelin