summaryrefslogtreecommitdiff
path: root/ci/run-linux32-build.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-02-06Merge branch 'js/vsts-ci'Libravatar Junio C Hamano1-1/+1
Prepare to run test suite on Azure Pipeline. * js/vsts-ci: (22 commits) test-date: drop unused parameter to getnanos() ci: parallelize testing on Windows ci: speed up Windows phase tests: optionally skip bin-wrappers/ t0061: workaround issues with --with-dashes and RUNTIME_PREFIX tests: add t/helper/ to the PATH with --with-dashes mingw: try to work around issues with the test cleanup tests: include detailed trace logs with --write-junit-xml upon failure tests: avoid calling Perl just to determine file sizes README: add a build badge (status of the Azure Pipelines build) mingw: be more generous when wrapping up the setitimer() emulation ci: use git-sdk-64-minimal build artifact ci: add a Windows job to the Azure Pipelines definition Add a build definition for Azure DevOps ci/lib.sh: add support for Azure Pipelines tests: optionally write results as JUnit-style .xml test-date: add a subcommand to measure times in shell scripts ci: use a junction on Windows instead of a symlink ci: inherit --jobs via MAKEFLAGS in run-build-and-tests ci/lib.sh: encapsulate Travis-specific things ...
2019-01-28ci: inherit --jobs via MAKEFLAGS in run-build-and-testsLibravatar Johannes Schindelin1-1/+1
Let's not decide in the generic ci/ part how many jobs to run in parallel; different CI configurations would favor a different number of parallel jobs, and it is easy enough to hand that information down via the `MAKEFLAGS` variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17travis-ci: don't be '--quiet' when running the testsLibravatar SZEDER Gábor1-1/+1
All Travis CI build jobs run the test suite with 'make --quiet test'. On one hand, being quiet doesn't save us from much clutter in the output: $ make test |wc -l 861 $ make --quiet test |wc -l 848 It only spares 13 lines, mostly the output of entering the 't/' directory and the pre- and post-cleanup commands, which is negligible compared to the ~700 lines printed while building Git and the ~850 lines of 'prove' output. On the other hand, it's asking for trouble. In our CI build scripts we build Git and run the test suite in two separate 'make' invocations. In a prelimiary version of one of the later patches in this series, to explicitly specify which compiler to use, I changed them to basically run: make CC=$CC make --quiet test naively thinking that it should Just Work... but then that 'make --quiet test' got all clever on me, noticed the changed build flags, and then proceeded to rebuild everything with the default 'cc'. And because of that '--quiet' option, it did so, well, quietly, only saying "* new build flags", and it was by mere luck that I happened to notice that something is amiss. Let's just drop that '--quiet' option when running the test suite in all build scripts. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30travis-ci: don't fail if user already exists on 32 bit Linux build jobLibravatar SZEDER Gábor1-1/+7
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>
2018-01-30travis-ci: don't run the test suite as root in the 32 bit Linux buildLibravatar SZEDER Gábor1-5/+25
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>
2018-01-30travis-ci: don't repeat the path of the cache directoryLibravatar SZEDER Gábor1-1/+1
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>
2018-01-30travis-ci: use 'set -e' in the 32 bit Linux build jobLibravatar SZEDER Gábor1-10/+10
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>
2018-01-30travis-ci: use 'set -x' for the commands under 'su' in the 32 bit Linux buildLibravatar SZEDER Gábor1-0/+1
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27travis-ci: save prove state for the 32 bit Linux buildLibravatar SZEDER Gábor1-0/+1
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>
2017-12-27travis-ci: fine tune the use of 'set -x' in 'ci/*' scriptsLibravatar SZEDER Gábor1-0/+2
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>
2017-03-06Travis: also test on 32-bit LinuxLibravatar Johannes Schindelin1-0/+30
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>