git/ci, branch v2.25.3

ci: prevent `perforce` from being quarantined

2020-02-27T17:58:42Z

The most recent Azure Pipelines macOS agents enable what Apple calls "System Integrity Protection". This makes `p4d -V` hang: there is some sort of GUI dialog waiting for the user to acknowledge that the copied binaries are legit and may be executed, but on build agents, there is no user who could acknowledge that. Let's ask Homebrew specifically to _not_ quarantine the Perforce binaries. Helped-by: Aleksandr Chebotov Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: ignore rubygems warning in the "Documentation" job

2020-02-10T17:52:27Z

A recent update in the Linux VM images used by Azure Pipelines surfaced a new problem in the "Documentation" job. Apparently, this warning appears 396 times on `stderr` when running `make doc`: /usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated This problem was already reported to the `rubygems` project via https://github.com/rubygems/rubygems/issues/3068. As there is nothing Git can do about this warning, and as the "Documentation" job reports this warning as a failure, let's just silence it and move on. Signed-off-by: Johannes Schindelin Acked-by: Taylor Blau Signed-off-by: Junio C Hamano

Merge branch 'sg/osx-force-gcc-9'

2019-12-06T23:09:21Z

TravisCI update. * sg/osx-force-gcc-9: ci: build Git with GCC 9 in the 'osx-gcc' build job

Merge branch 'sg/test-bool-env'

2019-12-05T20:52:48Z

Recently we have declared that GIT_TEST_* variables take the usual boolean values (it used to be that some used "non-empty means true" and taking GIT_TEST_VAR=YesPlease as true); make sure we notice and fail when non-bool strings are given to these variables. * sg/test-bool-env: t5608-clone-2gb.sh: turn GIT_TEST_CLONE_2GB into a bool tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values

Merge branch 'jc/azure-ci-osx-fix-fix'

2019-12-05T20:52:44Z

CI jobs for macOS has been made less chatty when updating perforce package used during testing. * jc/azure-ci-osx-fix-fix: ci(osx): update homebrew-cask repository with less noise

ci: build Git with GCC 9 in the 'osx-gcc' build job

2019-11-29T21:18:48Z

Our 'osx-gcc' build job on Travis CI relied on GCC 8 being installed (but not linked) in the image we use [1]. Alas, since the last update of this image a few days ago this is not the case anymore, and now it contains GCC 9 (installed and linked) instead of GCC 8. The results are failed 'osx-gcc' jobs, because they can't find the 'gcc-8' command [2]. Let's move on to use GCC 9, with hopefully better error reporting and improved -Wfoo flags and what not. On Travis CI this has the benefit that we can spare a few seconds while installing dependencies, because it already comes pre-installed, at least for now. The Azure Pipelines OSX image doesn't include GCC, so we have to install it ourselves anyway, and then we might as well install the newer version. In a vain attempt I tried to future-proof this a bit: - Install 'gcc@9' specifically, so we'll still get what we want even after GCC 10 comes out, and the "plain" 'gcc' package starts to refer to 'gcc@10'. - Run both 'brew install gcc@9' and 'brew link gcc@9'. If 'gcc@9' is already installed and linked, then both commands are noop and exit with success. But as we saw in the past, sometimes the image contains the expected GCC package installed but not linked, so maybe it will happen again in the future as well. In that case 'brew install' is still a noop, and instructs the user to run 'brew link' instead, so that's what we'll do. And if 'gcc@9' is not installed, then 'brew install' will install it, and the subsequent 'brew link' becomes a noop. An additional benefit of this patch is that from now on we won't unnecessarily install GCC and its dependencies in the 'osx-clang' jobs on Azure Pipelines. [1] 7d4733c501 (ci: fix GCC install in the Travis CI GCC OSX job, 2019-10-24) [2] https://travis-ci.org/git/git/jobs/615442297#L333 Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

t5608-clone-2gb.sh: turn GIT_TEST_CLONE_2GB into a bool

2019-11-23T02:16:10Z

The GIT_TEST_CLONE_2GB environment variable is only ever checked with 'test -z' in 't5608-clone-2gb.sh', so any non-empty value is interpreted as "yes, run these expensive tests", even 'GIT_TEST_CLONE_2GB=NoThanks'. Similar GIT_TEST_* environment variables have already been turned into bools in 3b072c577b (tests: replace test_tristate with "git env--helper", 2019-06-21), so let's turn GIT_TEST_CLONE_2GB into a bool as well, to follow suit. Our CI builds set GIT_TEST_CLONE_2GB=YesPlease, so adjust them accordingly, thus removing the last 'YesPlease' from our CI scripts. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

ci(osx): update homebrew-cask repository with less noise

2019-11-20T02:55:46Z

The OSX CI build procedure updates the homebrew-cask repository before attempting to install perforce again, after seeing an installation failure. This involves a "git pull" that by default computes and outputs diffstat, which would only grow as the time goes by and the repository cast in stone in the CI build image becomes more and more stale relative to the upstream repository in the outside world. Suppress the diffstat to both save cycles to generate it, and strain on the eyeballs to skip it. Reported-by: SZEDER Gábor Helped-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'sg/ci-osx-gcc8-fix'

2019-10-24T04:34:03Z

CI build fix. * sg/ci-osx-gcc8-fix: ci: fix GCC install in the Travis CI GCC OSX job

ci: fix GCC install in the Travis CI GCC OSX job

2019-10-24T02:31:07Z

A few days ago Travis CI updated their existing OSX images, including the Homebrew database in the xcode10.1 OSX image that we use. Since then installing dependencies in the 'osx-gcc' job fails when it tries to link gcc@8: + brew link gcc@8 Error: No such keg: /usr/local/Cellar/gcc@8 GCC8 is still installed but not linked to '/usr/local' in the updated image, as it was before this update, but now we have to link it by running 'brew link gcc'. So let's do that then, and fall back to linking gcc@8 if it doesn't, just to be sure. Our builds on Azure Pipelines are unaffected by this issue. The OSX image over there doesn't contain the gcc@8 package, so we have to 'brew install' it, which already takes care of linking it to '/usr/local'. After that the 'brew link gcc' command added by this patch fails, but the ||-chained fallback 'brew link gcc@8' command succeeds with an "already linked" warning. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano