2017-09-10 14:44:28 +00:00
|
|
|
#!/usr/bin/env bash
|
|
|
|
#
|
|
|
|
# Install dependencies required to build and test Git on Linux and macOS
|
|
|
|
#
|
|
|
|
|
2019-01-27 23:26:50 +00:00
|
|
|
. ${0%/*}/lib.sh
|
2017-09-10 14:44:28 +00:00
|
|
|
|
2017-09-11 01:18:29 +00:00
|
|
|
P4WHENCE=http://filehost.perforce.com/perforce/r$LINUX_P4_VERSION
|
|
|
|
LFSWHENCE=https://github.com/github/git-lfs/releases/download/v$LINUX_GIT_LFS_VERSION
|
|
|
|
|
travis-ci: introduce a $jobname variable for 'ci/*' scripts
A couple of 'ci/*' scripts are shared between different build jobs:
'ci/lib-travisci.sh', being a common library, is sourced from almost
every script, while 'ci/install-dependencies.sh', 'ci/run-build.sh'
and 'ci/run-tests.sh' are shared between the "regular" GCC and Clang
Linux and OSX build jobs, and the latter two scripts are used in the
GETTEXT_POISON Linux build job as well.
Our builds could benefit from these shared scripts being able to
easily tell which build job they are taking part in. Now, it's
already quite easy to tell apart Linux vs OSX and GCC vs Clang build
jobs, but it gets trickier with all the additional Linux-based build
jobs included explicitly in the build matrix.
Unfortunately, Travis CI doesn't provide much help in this regard.
The closest we've got is the $TRAVIS_JOB_NUMBER variable, the value of
which is two dot-separated integers, where the second integer
indicates a particular build job. While it would be possible to use
that second number to identify the build job in our shared scripts, it
doesn't seem like a good idea to rely on that:
- Though the build job numbering sequence seems to be stable so far,
Travis CI's documentation doesn't explicitly states that it is
indeed stable and will remain so in the future. And even if it
were stable,
- if we were to remove or insert a build job in the middle, then the
job numbers of all subsequent build jobs would change accordingly.
So roll our own means of simple build job identification and introduce
the $jobname environment variable in our builds, setting it in the
environments of the explicitly included jobs in '.travis.yml', while
constructing one in 'ci/lib-travisci.sh' as the combination of the OS
and compiler name for the GCC and Clang Linux and OSX build jobs. Use
$jobname instead of $TRAVIS_OS_NAME in scripts taking different
actions based on the OS and build job (when installing P4 and Git LFS
dependencies and including them in $PATH). The following two patches
will also rely on $jobname.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11 23:34:44 +00:00
|
|
|
case "$jobname" in
|
|
|
|
linux-clang|linux-gcc)
|
2018-11-01 11:47:14 +00:00
|
|
|
sudo apt-add-repository -y "ppa:ubuntu-toolchain-r/test"
|
|
|
|
sudo apt-get -q update
|
|
|
|
sudo apt-get -q -y install language-pack-is git-svn apache2
|
|
|
|
case "$jobname" in
|
|
|
|
linux-gcc)
|
|
|
|
sudo apt-get -q -y install gcc-8
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
travis-ci: fix running P4 and Git LFS tests in Linux build jobs
Linux build jobs on Travis CI skip the P4 and Git LFS tests since
commit 657343a60 (travis-ci: move Travis CI code into dedicated
scripts, 2017-09-10), claiming there are no P4 or Git LFS installed.
The reason is that P4 and Git LFS binaries are not installed to a
directory in the default $PATH, but their directories are prepended to
$PATH. This worked just fine before said commit, because $PATH was
set in a scriptlet embedded in our '.travis.yml', thus its new value
was visible during the rest of the build job. However, after these
embedded scriptlets were moved into dedicated scripts executed in
separate shell processes, any variable set in one of those scripts is
only visible in that single script but not in any of the others. In
this case, 'ci/install-dependencies.sh' downloads P4 and Git LFS and
modifies $PATH, but to no effect, because 'ci/run-tests.sh' only sees
Travis CI's default $PATH.
Move adjusting $PATH to 'ci/lib-travisci.sh', which is sourced in all
other 'ci/' scripts, so all those scripts will see the updated $PATH
value.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-01 11:55:35 +00:00
|
|
|
mkdir --parents "$P4_PATH"
|
|
|
|
pushd "$P4_PATH"
|
2017-09-11 01:18:29 +00:00
|
|
|
wget --quiet "$P4WHENCE/bin.linux26x86_64/p4d"
|
|
|
|
wget --quiet "$P4WHENCE/bin.linux26x86_64/p4"
|
|
|
|
chmod u+x p4d
|
|
|
|
chmod u+x p4
|
|
|
|
popd
|
travis-ci: fix running P4 and Git LFS tests in Linux build jobs
Linux build jobs on Travis CI skip the P4 and Git LFS tests since
commit 657343a60 (travis-ci: move Travis CI code into dedicated
scripts, 2017-09-10), claiming there are no P4 or Git LFS installed.
The reason is that P4 and Git LFS binaries are not installed to a
directory in the default $PATH, but their directories are prepended to
$PATH. This worked just fine before said commit, because $PATH was
set in a scriptlet embedded in our '.travis.yml', thus its new value
was visible during the rest of the build job. However, after these
embedded scriptlets were moved into dedicated scripts executed in
separate shell processes, any variable set in one of those scripts is
only visible in that single script but not in any of the others. In
this case, 'ci/install-dependencies.sh' downloads P4 and Git LFS and
modifies $PATH, but to no effect, because 'ci/run-tests.sh' only sees
Travis CI's default $PATH.
Move adjusting $PATH to 'ci/lib-travisci.sh', which is sourced in all
other 'ci/' scripts, so all those scripts will see the updated $PATH
value.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-01 11:55:35 +00:00
|
|
|
mkdir --parents "$GIT_LFS_PATH"
|
|
|
|
pushd "$GIT_LFS_PATH"
|
2017-09-11 01:18:29 +00:00
|
|
|
wget --quiet "$LFSWHENCE/git-lfs-linux-amd64-$LINUX_GIT_LFS_VERSION.tar.gz"
|
|
|
|
tar --extract --gunzip --file "git-lfs-linux-amd64-$LINUX_GIT_LFS_VERSION.tar.gz"
|
|
|
|
cp git-lfs-$LINUX_GIT_LFS_VERSION/git-lfs .
|
|
|
|
popd
|
2017-09-10 14:44:28 +00:00
|
|
|
;;
|
travis-ci: introduce a $jobname variable for 'ci/*' scripts
A couple of 'ci/*' scripts are shared between different build jobs:
'ci/lib-travisci.sh', being a common library, is sourced from almost
every script, while 'ci/install-dependencies.sh', 'ci/run-build.sh'
and 'ci/run-tests.sh' are shared between the "regular" GCC and Clang
Linux and OSX build jobs, and the latter two scripts are used in the
GETTEXT_POISON Linux build job as well.
Our builds could benefit from these shared scripts being able to
easily tell which build job they are taking part in. Now, it's
already quite easy to tell apart Linux vs OSX and GCC vs Clang build
jobs, but it gets trickier with all the additional Linux-based build
jobs included explicitly in the build matrix.
Unfortunately, Travis CI doesn't provide much help in this regard.
The closest we've got is the $TRAVIS_JOB_NUMBER variable, the value of
which is two dot-separated integers, where the second integer
indicates a particular build job. While it would be possible to use
that second number to identify the build job in our shared scripts, it
doesn't seem like a good idea to rely on that:
- Though the build job numbering sequence seems to be stable so far,
Travis CI's documentation doesn't explicitly states that it is
indeed stable and will remain so in the future. And even if it
were stable,
- if we were to remove or insert a build job in the middle, then the
job numbers of all subsequent build jobs would change accordingly.
So roll our own means of simple build job identification and introduce
the $jobname environment variable in our builds, setting it in the
environments of the explicitly included jobs in '.travis.yml', while
constructing one in 'ci/lib-travisci.sh' as the combination of the OS
and compiler name for the GCC and Clang Linux and OSX build jobs. Use
$jobname instead of $TRAVIS_OS_NAME in scripts taking different
actions based on the OS and build job (when installing P4 and Git LFS
dependencies and including them in $PATH). The following two patches
will also rely on $jobname.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11 23:34:44 +00:00
|
|
|
osx-clang|osx-gcc)
|
travis-ci: make the OSX build jobs' 'brew update' more quiet
Before installing the necessary dependencies, our OSX build jobs run
'brew update --quiet'. This is problematic for two reasons:
- This '--quiet' flag apparently broke overnight, resulting in
errored builds:
+brew update --quiet
==> Downloading https://homebrew.bintray.com/bottles-portable-ruby/portable-ruby-2.3.7.mavericks.bottle.tar.gz
######################################################################## 100.0%
==> Pouring portable-ruby-2.3.7.mavericks.bottle.tar.gz
Usage: brew update_report [--preinstall]
The Ruby implementation of brew update. Never called manually.
--preinstall Run in 'auto-update' mode (faster, less
output).
-f, --force Override warnings and enable potentially
unsafe operations.
-d, --debug Display any debugging information.
-v, --verbose Make some output more verbose.
-h, --help Show this message.
Error: invalid option: --quiet
The command "ci/install-dependencies.sh" failed and exited with 1 during .
I belive that this breakage will be noticed and fixed soon-ish, so
we could probably just wait a bit for this issue to solve itself,
but:
- 'brew update --quiet' wasn't really quiet in the first place, as
it listed over about 2000 lines worth of available packages that
we absolutely don't care about, see e.g. one of the latest
'master' builds:
https://travis-ci.org/git/git/jobs/486134962#L113
So drop this '--quiet' option and redirect 'brew update's standard
output to /dev/null to make it really quiet, thereby making the OSX
builds work again despite the above mentioned breakage.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-02 16:34:21 +00:00
|
|
|
brew update >/dev/null
|
2017-09-11 01:18:29 +00:00
|
|
|
# Uncomment this if you want to run perf tests:
|
|
|
|
# brew install gnu-time
|
ci/lib.sh: encapsulate Travis-specific things
The upcoming patches will allow building git.git via Azure Pipelines
(i.e. Azure DevOps' Continuous Integration), where variable names and
URLs look a bit different than in Travis CI.
Also, the configurations of the available agents are different. For
example, Travis' and Azure Pipelines' macOS agents are set up
differently, so that on Travis, we have to install the git-lfs and
gettext Homebrew packages, and on Azure Pipelines we do not need to.
Likewise, Azure Pipelines' Ubuntu agents already have asciidoctor
installed.
Finally, on Azure Pipelines the natural way is not to base64-encode tar
files of the trash directories of failed tests, but to publish build
artifacts instead. Therefore, that code to log those base64-encoded tar
files is guarded to be Travis-specific.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-27 23:26:51 +00:00
|
|
|
test -z "$BREW_INSTALL_PACKAGES" ||
|
|
|
|
brew install $BREW_INSTALL_PACKAGES
|
2017-09-11 01:18:29 +00:00
|
|
|
brew link --force gettext
|
|
|
|
brew install caskroom/cask/perforce
|
travis-ci: build with the right compiler
Our 'Makefile' hardcodes the compiler to build Git as 'CC = cc'. This
CC variable can be overridden from the command line, i.e. 'make
CC=gcc-X.Y' will build with that particular GCC version, but not from
the environment, i.e. 'CC=gcc-X.Y make' will still build with whatever
'cc' happens to be on the platform.
Our build jobs on Travis CI are badly affected by this. In the build
matrix we have dedicated build jobs to build Git with GCC and Clang
both on Linux and macOS from the very beginning (522354d70f (Add
Travis CI support, 2015-11-27)). Alas, this never really worked as
supposed to, because Travis CI specifies the compiler for those build
jobs as 'export CC=gcc' and 'export CC=clang' (which works fine for
projects built with './configure && make'). Consequently, our
'linux-clang' build job has always used GCC, because that's where 'cc'
points at in Travis CI's Linux images, while the 'osx-gcc' build job
has always used Clang. Furthermore, 37fa4b3c78 (travis-ci: run gcc-8
on linux-gcc jobs, 2018-05-19) added an 'export CC=gcc-8' in an
attempt to build with a more modern compiler, but to no avail.
Set MAKEFLAGS with CC based on the $CC environment variable, so 'make'
will run the "right" compiler. The Xcode 10.1 macOS image on Travis
CI already contains the gcc@8 package from Homebrew, but we have to
'brew link' it first to be able to use it.
So with this patch our build jobs will build Git with the following
compiler versions:
linux-clang: clang version 5.0.0 (tags/RELEASE_500/final)
linux-gcc: gcc-8 (Ubuntu 8.1.0-5ubuntu1~14.04) 8.1.0
osx-clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)
osx-gcc: gcc-8 (Homebrew GCC 8.2.0) 8.2.0
GETTEXT_POISON: gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17 01:29:13 +00:00
|
|
|
case "$jobname" in
|
|
|
|
osx-gcc)
|
|
|
|
brew link gcc@8
|
|
|
|
;;
|
|
|
|
esac
|
2017-09-10 14:44:28 +00:00
|
|
|
;;
|
2018-11-01 11:47:14 +00:00
|
|
|
StaticAnalysis)
|
|
|
|
sudo apt-get -q update
|
|
|
|
sudo apt-get -q -y install coccinelle
|
|
|
|
;;
|
|
|
|
Documentation)
|
|
|
|
sudo apt-get -q update
|
|
|
|
sudo apt-get -q -y install asciidoc xmlto
|
|
|
|
;;
|
2017-09-10 14:44:28 +00:00
|
|
|
esac
|
|
|
|
|
2018-11-01 11:47:14 +00:00
|
|
|
if type p4d >/dev/null && type p4 >/dev/null
|
|
|
|
then
|
|
|
|
echo "$(tput setaf 6)Perforce Server Version$(tput sgr0)"
|
|
|
|
p4d -V | grep Rev.
|
|
|
|
echo "$(tput setaf 6)Perforce Client Version$(tput sgr0)"
|
|
|
|
p4 -V | grep Rev.
|
|
|
|
fi
|
|
|
|
if type git-lfs >/dev/null
|
|
|
|
then
|
|
|
|
echo "$(tput setaf 6)Git-LFS Version$(tput sgr0)"
|
|
|
|
git-lfs version
|
|
|
|
fi
|