2015-11-27 09:23:27 +00:00
|
|
|
language: c
|
|
|
|
|
|
2016-01-26 09:53:42 +00:00
|
|
|
cache:
|
|
|
|
|
directories:
|
|
|
|
|
- $HOME/travis-cache
|
|
|
|
|
|
2015-11-27 09:23:27 +00:00
|
|
|
os:
|
|
|
|
|
- linux
|
|
|
|
|
- osx
|
|
|
|
|
|
2019-01-17 01:29:12 +00:00
|
|
|
osx_image: xcode10.1
|
|
|
|
|
|
2015-11-27 09:23:27 +00:00
|
|
|
compiler:
|
|
|
|
|
- clang
|
|
|
|
|
- gcc
|
|
|
|
|
|
2016-05-04 08:38:36 +00:00
|
|
|
matrix:
|
|
|
|
|
include:
|
2021-01-20 18:27:57 +00:00
|
|
|
- env: jobname=linux-gcc-default
|
2017-05-05 15:40:53 +00:00
|
|
|
os: linux
|
|
|
|
|
compiler:
|
|
|
|
|
addons:
|
|
|
|
|
before_install:
|
travis-ci: build with GCC 4.8 as well
C99 'for' loop initial declaration, i.e. 'for (int i = 0; i < n; i++)',
is not allowed in Git's codebase yet, to maintain compatibility with
some older compilers.
Our Travis CI builds used to catch 'for' loop initial declarations,
because the GETTEXT_POISON job has always built Git with the default
'cc', which in Travis CI's previous default Linux image (based on
Ubuntu 14.04 Trusty) is GCC 4.8, and that GCC version errors out on
this construct (not only with DEVELOPER=1, but with our default CFLAGS
as well). Alas, that's not the case anymore, becase after 14.04's EOL
Travis CI's current default Linux image is based on Ubuntu 16.04
Xenial [1] and its default 'cc' is now GCC 5.4, which, just like all
later GCC and Clang versions, simply accepts this construct, even if
we don't explicitly specify '-std=c99'.
Ideally we would adjust our CFLAGS used with DEVELOPER=1 to catch this
undesired construct already when contributors build Git on their own
machines. Unfortunately, however, there seems to be no compiler
option that would catch only this particular construct without choking
on many other things, e.g. while a later compiler with '-std=c90'
and/or '-ansi' does catch this construct, it can't build Git because
of several screenfulls of other errors.
Add the 'linux-gcc-4.8' job to Travis CI, in order to build Git with
GCC 4.8, and thus to timely catch any 'for' loop initial declarations.
To catch those it's sufficient to only build Git with GCC 4.8, so
don't run the test suite in this job, because 'make test' takes rather
long [2], and it's already run five times in other jobs, so we
wouldn't get our time's worth.
[1] The Azure Pipelines builds have been using Ubuntu 16.04 images
from the start, so I belive they never caught 'for' loop initial
declarations.
[2] On Travis CI 'make test' alone would take about 9 minutes in this
new job (without running httpd, Subversion, and P4 tests). For
comparison, starting the job and building Git with GCC 4.8 takes
only about 2 minutes.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-18 15:22:34 +00:00
|
|
|
- env: jobname=linux-gcc-4.8
|
|
|
|
|
os: linux
|
|
|
|
|
dist: trusty
|
|
|
|
|
compiler:
|
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
|
|
|
- env: jobname=Linux32
|
2017-03-05 18:25:19 +00:00
|
|
|
os: linux
|
2017-04-11 08:33:09 +00:00
|
|
|
compiler:
|
2017-12-27 16:36:01 +00:00
|
|
|
addons:
|
2017-03-05 18:25:19 +00:00
|
|
|
services:
|
|
|
|
|
- docker
|
|
|
|
|
before_install:
|
2020-04-04 01:08:48 +00:00
|
|
|
script: ci/run-docker.sh
|
2020-04-04 01:08:50 +00:00
|
|
|
- env: jobname=linux-musl
|
|
|
|
|
os: linux
|
|
|
|
|
compiler:
|
|
|
|
|
addons:
|
|
|
|
|
services:
|
|
|
|
|
- docker
|
|
|
|
|
before_install:
|
|
|
|
|
script: ci/run-docker.sh
|
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
|
|
|
- env: jobname=StaticAnalysis
|
2017-04-11 07:26:37 +00:00
|
|
|
os: linux
|
|
|
|
|
compiler:
|
2017-09-10 14:44:28 +00:00
|
|
|
script: ci/run-static-analysis.sh
|
2017-04-11 07:26:37 +00:00
|
|
|
after_failure:
|
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
|
|
|
- env: jobname=Documentation
|
2016-05-04 08:38:36 +00:00
|
|
|
os: linux
|
2017-04-11 08:33:09 +00:00
|
|
|
compiler:
|
2016-05-04 08:38:36 +00:00
|
|
|
script: ci/test-documentation.sh
|
|
|
|
|
after_failure:
|
|
|
|
|
|
2017-09-10 14:44:28 +00:00
|
|
|
before_install: ci/install-dependencies.sh
|
travis-ci: build Git during the 'script' phase
Ever since we started building and testing Git on Travis CI (522354d70
(Add Travis CI support, 2015-11-27)), we build Git in the
'before_script' phase and run the test suite in the 'script' phase
(except in the later introduced 32 bit Linux and Windows build jobs,
where we build in the 'script' phase').
Contrarily, the Travis CI practice is to build and test in the
'script' phase; indeed Travis CI's default build command for the
'script' phase of C/C++ projects is:
./configure && make && make test
The reason why Travis CI does it this way and why it's a better
approach than ours lies in how unsuccessful build jobs are
categorized. After something went wrong in a build job, its state can
be:
- 'failed', if a command in the 'script' phase returned an error.
This is indicated by a red 'X' on the Travis CI web interface.
- 'errored', if a command in the 'before_install', 'install', or
'before_script' phase returned an error, or the build job exceeded
the time limit. This is shown as a red '!' on the web interface.
This makes it easier, both for humans looking at the Travis CI web
interface and for automated tools querying the Travis CI API, to
decide when an unsuccessful build is our responsibility requiring
human attention, i.e. when a build job 'failed' because of a compiler
error or a test failure, and when it's caused by something beyond our
control and might be fixed by restarting the build job, e.g. when a
build job 'errored' because a dependency couldn't be installed due to
a temporary network error or because the OSX build job exceeded its
time limit.
The drawback of building Git in the 'before_script' phase is that one
has to check the trace log of all 'errored' build jobs, too, to see
what caused the error, as it might have been caused by a compiler
error. This requires additional clicks and page loads on the web
interface and additional complexity and API requests in automated
tools.
Therefore, move building Git from the 'before_script' phase to the
'script' phase, updating the script's name accordingly as well.
'ci/run-builds.sh' now becomes basically empty, remove it. Several of
our build job configurations override our default 'before_script' to
do nothing; with this change our default 'before_script' won't do
anything, either, so remove those overriding directives as well.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08 17:22:14 +00:00
|
|
|
script: ci/run-build-and-tests.sh
|
2017-09-10 14:44:28 +00:00
|
|
|
after_failure: ci/print-test-failures.sh
|
2015-11-27 09:23:27 +00:00
|
|
|
|
|
|
|
|
notifications:
|
|
|
|
|
email: false
|