2015-11-27 09:23:27 +00:00
|
|
|
language: c
|
|
|
|
|
|
2016-01-26 09:53:43 +00:00
|
|
|
sudo: false
|
|
|
|
|
|
2016-01-26 09:53:42 +00:00
|
|
|
cache:
|
|
|
|
|
directories:
|
|
|
|
|
- $HOME/travis-cache
|
|
|
|
|
|
2015-11-27 09:23:27 +00:00
|
|
|
os:
|
|
|
|
|
- linux
|
|
|
|
|
- osx
|
|
|
|
|
|
|
|
|
|
compiler:
|
|
|
|
|
- clang
|
|
|
|
|
- gcc
|
|
|
|
|
|
|
|
|
|
addons:
|
|
|
|
|
apt:
|
|
|
|
|
packages:
|
|
|
|
|
- language-pack-is
|
2016-05-19 09:10:08 +00:00
|
|
|
- git-svn
|
2016-05-19 08:45:11 +00:00
|
|
|
- apache2
|
2015-11-27 09:23:27 +00:00
|
|
|
|
2016-05-04 08:38:36 +00:00
|
|
|
matrix:
|
|
|
|
|
include:
|
travis-ci: move setting environment variables to 'ci/lib-travisci.sh'
Our '.travis.yml's 'env.global' section sets a bunch of environment
variables for all build jobs, though none of them actually affects all
build jobs. It's convenient for us, and in most cases it works just
fine, because irrelevant environment variables are simply ignored.
However, $GIT_SKIP_TESTS is an exception: it tells the test harness to
skip the two test scripts that are prone to occasional failures on
OSX, but as it's set for all build jobs those tests are not run in any
of the build jobs that are capable to run them reliably, either.
Therefore $GIT_SKIP_TESTS should only be set in the OSX build jobs,
but those build jobs are included in the build matrix implicitly (i.e.
by combining the matrix keys 'os' and 'compiler'), and there is no way
to set an environment variable only for a subset of those implicit
build jobs. (Unless we were to add new scriptlets to '.travis.yml',
which is exactly the opposite direction that we took with commit
657343a60 (travis-ci: move Travis CI code into dedicated scripts,
2017-09-10)).
So move setting $GIT_SKIP_TESTS to 'ci/lib-travisci.sh', where it can
trivially be set only for the OSX build jobs.
Furthermore, move setting all other environment variables from
'.travis.yml' to 'ci/lib-travisci.sh', too, because a couple of
environment variables are already set there, and this way all
environment variables will be set in the same place. All the logic
controlling our builds is already in the 'ci/*' scripts anyway, so
there is really no good reason to keep the environment variables
separately.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11 23:34:45 +00:00
|
|
|
- env: jobname=GETTEXT_POISON
|
2017-05-05 15:40:53 +00:00
|
|
|
os: linux
|
|
|
|
|
compiler:
|
|
|
|
|
addons:
|
|
|
|
|
before_install:
|
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=Windows
|
2017-03-24 11:37:47 +00:00
|
|
|
os: linux
|
|
|
|
|
compiler:
|
|
|
|
|
addons:
|
|
|
|
|
before_install:
|
|
|
|
|
before_script:
|
|
|
|
|
script:
|
|
|
|
|
- >
|
|
|
|
|
test "$TRAVIS_REPO_SLUG" != "git/git" ||
|
|
|
|
|
ci/run-windows-build.sh $TRAVIS_BRANCH $(git rev-parse HEAD)
|
|
|
|
|
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=Linux32
|
2017-03-05 18:25:19 +00:00
|
|
|
os: linux
|
2017-04-11 08:33:09 +00:00
|
|
|
compiler:
|
2017-03-05 18:25:19 +00:00
|
|
|
services:
|
|
|
|
|
- docker
|
|
|
|
|
before_install:
|
|
|
|
|
before_script:
|
2017-09-10 14:44:28 +00:00
|
|
|
script: ci/run-linux32-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:
|
|
|
|
|
addons:
|
|
|
|
|
apt:
|
|
|
|
|
packages:
|
|
|
|
|
- coccinelle
|
|
|
|
|
before_install:
|
2017-11-01 11:56:44 +00:00
|
|
|
before_script:
|
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
|
|
|
addons:
|
|
|
|
|
apt:
|
|
|
|
|
packages:
|
|
|
|
|
- asciidoc
|
|
|
|
|
- xmlto
|
|
|
|
|
before_install:
|
2017-09-10 14:44:28 +00:00
|
|
|
before_script:
|
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
|
|
|
|
|
before_script: ci/run-build.sh
|
|
|
|
|
script: ci/run-tests.sh
|
|
|
|
|
after_failure: ci/print-test-failures.sh
|
2015-11-27 09:23:27 +00:00
|
|
|
|
|
|
|
|
notifications:
|
|
|
|
|
email: false
|