2017-09-10 16:44:28 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
2020-04-04 03:08:48 +02:00
|
|
|
# Download and run Docker image to build and test Git
|
2017-09-10 16:44:28 +02:00
|
|
|
#
|
|
|
|
|
|
2019-01-28 00:26:50 +01:00
|
|
|
. ${0%/*}/lib.sh
|
2017-09-10 16:44:28 +02:00
|
|
|
|
2020-04-04 03:08:48 +02:00
|
|
|
case "$jobname" in
|
2021-11-23 17:29:10 +01:00
|
|
|
linux32)
|
2020-04-04 03:08:48 +02:00
|
|
|
CI_CONTAINER="daald/ubuntu32:xenial"
|
|
|
|
|
;;
|
2020-04-04 03:08:50 +02:00
|
|
|
linux-musl)
|
|
|
|
|
CI_CONTAINER=alpine
|
|
|
|
|
;;
|
2020-04-04 03:08:48 +02:00
|
|
|
*)
|
|
|
|
|
exit 1
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
docker pull "$CI_CONTAINER"
|
2017-09-10 16:44:28 +02:00
|
|
|
|
|
|
|
|
# Use the following command to debug the docker build locally:
|
2020-04-04 03:08:48 +02:00
|
|
|
# <host-user-id> must be 0 if podman is used as drop-in replacement for docker
|
|
|
|
|
# $ docker run -itv "${PWD}:/usr/src/git" --entrypoint /bin/sh "$CI_CONTAINER"
|
2020-04-04 03:08:47 +02:00
|
|
|
# root@container:/# export jobname=<jobname>
|
2020-04-04 03:08:48 +02:00
|
|
|
# root@container:/# /usr/src/git/ci/run-docker-build.sh <host-user-id>
|
2017-09-10 16:44:28 +02:00
|
|
|
|
2021-11-23 17:29:08 +01:00
|
|
|
container_cache_dir=/tmp/container-cache
|
2018-01-29 18:17:11 +01:00
|
|
|
|
2017-09-10 16:44:28 +02:00
|
|
|
docker run \
|
|
|
|
|
--interactive \
|
|
|
|
|
--env DEVELOPER \
|
|
|
|
|
--env DEFAULT_TEST_TARGET \
|
|
|
|
|
--env GIT_PROVE_OPTS \
|
|
|
|
|
--env GIT_TEST_OPTS \
|
|
|
|
|
--env GIT_TEST_CLONE_2GB \
|
ci: make MAKEFLAGS available inside the Docker container in the Linux32 job
Once upon a time we ran 'make --jobs=2 ...' to build Git, its
documentation, or to apply Coccinelle semantic patches. Then commit
eaa62291ff (ci: inherit --jobs via MAKEFLAGS in run-build-and-tests,
2019-01-27) came along, and started using the MAKEFLAGS environment
variable to centralize setting the number of parallel jobs in
'ci/libs.sh'. Alas, it forgot to update 'ci/run-linux32-docker.sh' to
make MAKEFLAGS available inside the Docker container running the 32
bit Linux job, and, consequently, since then that job builds Git
sequentially, and it ignores any Makefile knobs that we might set in
MAKEFLAGS (though we don't set any for the 32 bit Linux job at the
moment).
So update the 'docker run' invocation in 'ci/run-linux32-docker.sh' to
make MAKEFLAGS available inside the Docker container as well. Set
CC=gcc for the 32 bit Linux job, because that's the compiler installed
in the 32 bit Linux Docker image that we use (Travis CI nowadays sets
CC=clang by default, but clang is not installed in this image).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-02 15:04:00 +02:00
|
|
|
--env MAKEFLAGS \
|
2020-04-04 03:08:47 +02:00
|
|
|
--env jobname \
|
2018-01-29 18:17:11 +01:00
|
|
|
--env cache_dir="$container_cache_dir" \
|
2017-09-10 16:44:28 +02:00
|
|
|
--volume "${PWD}:/usr/src/git" \
|
2018-01-29 18:17:11 +01:00
|
|
|
--volume "$cache_dir:$container_cache_dir" \
|
2020-04-04 03:08:48 +02:00
|
|
|
"$CI_CONTAINER" \
|
|
|
|
|
/usr/src/git/ci/run-docker-build.sh $(id -u $USER)
|
travis-ci: record and skip successfully built trees
Travis CI dutifully builds and tests each new branch tip, even if its
tree has previously been successfully built and tested. This happens
often enough in contributors' workflows, when a work-in-progress
branch is rebased changing e.g. only commit messages or the order or
number of commits while leaving the resulting code intact, and is then
pushed to a Travis CI-enabled GitHub fork.
This is wasting Travis CI's resources and is sometimes scary-annoying
when the new tip commit with a tree identical to the previous,
successfully tested one is suddenly reported in red, because one of
the OSX build jobs happened to exceed the time limit yet again.
So extend our Travis CI build scripts to skip building commits whose
trees have previously been successfully built and tested. Use the
Travis CI cache feature to keep a record of the object names of trees
that tested successfully, in a plain and simple flat text file, one
line per tree object name. Append the current tree's object name at
the end of every successful build job to this file, along with a bit
of additional info about the build job (commit object name, Travis CI
job number and id). Limit the size of this file to 1000 records, to
prevent it from growing too large for git/git's forever living
integration branches. Check, using a simple grep invocation, in each
build job whether the current commit's tree is already in there, and
skip the build if it is. Include a message in the skipped build job's
trace log, containing the URL to the build job successfully testing
that tree for the first time and instructions on how to force a
re-build. Catch the case when a build job, which successfully built
and tested a particular tree for the first time, is restarted and omit
the URL of the previous build job's trace log, as in this case it's
the same build job and the trace log has just been overwritten.
Note: this won't kick in if two identical trees are on two different
branches, because Travis CI caches are not shared between build jobs
of different branches.
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-31 11:12:05 +01:00
|
|
|
|
2017-12-31 17:02:06 +01:00
|
|
|
check_unignored_build_artifacts
|
|
|
|
|
|
travis-ci: record and skip successfully built trees
Travis CI dutifully builds and tests each new branch tip, even if its
tree has previously been successfully built and tested. This happens
often enough in contributors' workflows, when a work-in-progress
branch is rebased changing e.g. only commit messages or the order or
number of commits while leaving the resulting code intact, and is then
pushed to a Travis CI-enabled GitHub fork.
This is wasting Travis CI's resources and is sometimes scary-annoying
when the new tip commit with a tree identical to the previous,
successfully tested one is suddenly reported in red, because one of
the OSX build jobs happened to exceed the time limit yet again.
So extend our Travis CI build scripts to skip building commits whose
trees have previously been successfully built and tested. Use the
Travis CI cache feature to keep a record of the object names of trees
that tested successfully, in a plain and simple flat text file, one
line per tree object name. Append the current tree's object name at
the end of every successful build job to this file, along with a bit
of additional info about the build job (commit object name, Travis CI
job number and id). Limit the size of this file to 1000 records, to
prevent it from growing too large for git/git's forever living
integration branches. Check, using a simple grep invocation, in each
build job whether the current commit's tree is already in there, and
skip the build if it is. Include a message in the skipped build job's
trace log, containing the URL to the build job successfully testing
that tree for the first time and instructions on how to force a
re-build. Catch the case when a build job, which successfully built
and tested a particular tree for the first time, is restarted and omit
the URL of the previous build job's trace log, as in this case it's
the same build job and the trace log has just been overwritten.
Note: this won't kick in if two identical trees are on two different
branches, because Travis CI caches are not shared between build jobs
of different branches.
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-31 11:12:05 +01:00
|
|
|
save_good_tree
|
