summaryrefslogtreecommitdiff
path: root/.travis.yml
AgeCommit message (Collapse)AuthorFilesLines
2019-03-01travis: remove the hack to build the Windows job on Azure PipelinesLibravatar Johannes Schindelin1-10/+0
Since Travis did not support Windows (and now only supports very limited Windows jobs, too limited for our use, the test suite would time out *all* the time), we added a hack where a Travis job would trigger an Azure Pipeline (which back then was still called VSTS Build), wait for it to finish (or time out), and download the log (if available). Needless to say that it was a horrible hack, necessitated by a bad situation. Nowadays, however, we have Azure Pipelines support, and do not need that hack anymore. So let's retire it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-17travis-ci: switch to Xcode 10.1 macOS imageLibravatar SZEDER Gábor1-0/+2
When building something with GCC installed from Homebrew in the default macOS (with Xcode 9.4) image on Travis CI, it errors out with something like this: /usr/local/Cellar/gcc/8.1.0/lib/gcc/8/gcc/x86_64-apple-darwin17.5.0/8.1.0/include-fixed/stdio.h:78:10: fatal error: _stdio.h: No such file or directory #include <_stdio.h> ^~~~~~~~~~ This seems to be a common problem affecting several projects, and the common solution is to use a Travis CI macOS image with more recent Xcode version, e.g. 10 or 10.1. While we don't use such a GCC yet, in the very next patch we will, so switch our OSX build jobs to use the Xcode 10.1 image. Compared to the Xcode 10 image, this has the benefit that it comes with GCC (v8.2) preinstalled from Homebrew. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19Merge branch 'ab/dynamic-gettext-poison'Libravatar Junio C Hamano1-1/+1
Our testing framework uses a special i18n "poisoned localization" feature to find messages that ought to stay constant but are incorrectly marked to be translated. This feature has been made into a runtime option (it used to be a compile-time option). * ab/dynamic-gettext-poison: Makefile: ease dynamic-gettext-poison transition i18n: make GETTEXT_POISON a runtime option
2018-11-09i18n: make GETTEXT_POISON a runtime optionLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON test parameter to only be a GIT_TEST_GETTEXT_POISON=<non-empty?> runtime parameter, to be consistent with other parameters documented in "Running tests with special setups" in t/README. When I added GETTEXT_POISON in bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) I was concerned with ensuring that the _() function would get constant folded if NO_GETTEXT was defined, and likewise that GETTEXT_POISON would be compiled out unless it was defined. But as the benchmark in my [1] shows doing a one-off runtime getenv("GIT_TEST_[...]") is trivial, and since GETTEXT_POISON was originally added the GIT_TEST_* env variables have become the common idiom for turning on special test setups. So change GETTEXT_POISON to work the same way. Now the GETTEXT_POISON=YesPlease compile-time option is gone, and running the tests with GIT_TEST_GETTEXT_POISON=[YesPlease|] can be toggled on/off without recompiling. This allows for conditionally amending tests to test with/without poison, similar to what 859fdc0c3c ("commit-graph: define GIT_TEST_COMMIT_GRAPH", 2018-08-29) did for GIT_TEST_COMMIT_GRAPH. Do some of that, now we e.g. always run the t0205-gettext-poison.sh test. I did enough there to remove the GETTEXT_POISON prerequisite, but its inverse C_LOCALE_OUTPUT is still around, and surely some tests using it can be converted to e.g. always set GIT_TEST_GETTEXT_POISON=. Notes on the implementation: * We still compile a dedicated GETTEXT_POISON build in Travis CI. Perhaps this should be revisited and integrated into the "linux-gcc" build, see ae59a4e44f ("travis: run tests with GIT_TEST_SPLIT_INDEX", 2018-01-07) for prior art in that area. Then again maybe not, see [2]. * We now skip a test in t0000-basic.sh under GIT_TEST_GETTEXT_POISON=YesPlease that wasn't skipped before. This test relies on C locale output, but due to an edge case in how the previous implementation of GETTEXT_POISON worked (reading it from GIT-BUILD-OPTIONS) wasn't enabling poison correctly. Now it does, and needs to be skipped. * The getenv() function is not reentrant, so out of paranoia about code of the form: printf(_("%s"), getenv("some-env")); call use_gettext_poison() in our early setup in git_setup_gettext() so we populate the "poison_requested" variable in a codepath that's won't suffer from that race condition. * We error out in the Makefile if you're still saying GETTEXT_POISON=YesPlease to prompt users to change their invocation. * We should not print out poisoned messages during the test initialization itself to keep it more readable, so the test library hides the variable if set in $GIT_TEST_GETTEXT_POISON_ORIG during setup. See [3]. See also [4] for more on the motivation behind this patch, and the history of the GETTEXT_POISON facility. 1. https://public-inbox.org/git/871s8gd32p.fsf@evledraar.gmail.com/ 2. https://public-inbox.org/git/20181102163725.GY30222@szeder.dev/ 3. https://public-inbox.org/git/20181022202241.18629-2-szeder.dev@gmail.com/ 4. https://public-inbox.org/git/878t2pd6yu.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02travis-ci: install packages in 'ci/install-dependencies.sh'Libravatar SZEDER Gábor1-21/+0
Ever since we started using Travis CI, we specified the list of packages to install in '.travis.yml' via the APT addon. While running our builds on Travis CI's container-based infrastructure we didn't have another choice, because that environment didn't support 'sudo', and thus we didn't have permission to install packages ourselves. With the switch to the VM-based infrastructure in the previous patch we do get a working 'sudo', so we can install packages by running 'sudo apt-get -y install ...' as well. Let's make use of this and install necessary packages in 'ci/install-dependencies.sh', so all the dependencies (i.e. both packages and "non-packages" (P4 and Git-LFS)) are handled in the same file. Install gcc-8 only in the 'linux-gcc' build job; so far it has been unnecessarily installed in the 'linux-clang' build job as well. Print the versions of P4 and Git-LFS conditionally, i.e. only when they have been installed; with this change even the static analysis and documentation build jobs start using 'ci/install-dependencies.sh' to install packages, and neither of these two build jobs depend on and thus install those. This change will presumably be beneficial for the upcoming Azure Pipelines integration [1]: preliminary versions of that patch series run a couple of 'apt-get' commands to install the necessary packages before running 'ci/install-dependencies.sh', but with this patch it will be sufficient to run only 'ci/install-dependencies.sh'. [1] https://public-inbox.org/git/1a22efe849d6da79f2c639c62a1483361a130238.1539598316.git.gitgitgadget@gmail.com/ Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-26travis-ci: no longer use containersLibravatar Sebastian Staudt1-2/+0
Travis CI will soon deprecate the container-based infrastructure enabled by `sudo: false` in ce59dffb34190e780be2fa9f449f842cadee9753. More info: https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures Signed-off-by: Sebastian Staudt <koraktor@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-21travis-ci: run gcc-8 on linux-gcc jobsLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Switch from gcc-4.8 to gcc-8. Newer compilers come with more warning checks (usually in -Wextra). Since -Wextra is enabled in developer mode (which is also enabled in travis), this lets travis report more warnings before other people do it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08travis-ci: build Git during the 'script' phaseLibravatar SZEDER Gábor1-6/+1
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>
2017-12-27travis-ci: don't install default addon packages for the 32 bit Linux buildLibravatar SZEDER Gábor1-0/+1
The 32 bit Linux build job compiles Git and runs the test suite in a Docker container, while the additional packages (apache2, git-svn, language-pack-is) are installed on the host, therefore don't have any effect and are unnecessary. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-12travis-ci: move setting environment variables to 'ci/lib-travisci.sh'Libravatar SZEDER Gábor1-17/+1
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-12travis-ci: introduce a $jobname variable for 'ci/*' scriptsLibravatar SZEDER Gábor1-5/+5
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-11-02travis-ci: don't build Git for the static analysis jobLibravatar SZEDER Gábor1-1/+1
The static analysis job on Travis CI builds Git ever since it was introduced in d8245bb3f (travis-ci: add static analysis build job to run coccicheck, 2017-04-11). However, Coccinelle, the only static analysis tool in use, only needs Git's source code to work and it doesn't care about built Git binaries at all. Spare some of Travis CI's resources and don't build Git for the static analysis job unnecessarily. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-11travis-ci: move Travis CI code into dedicated scriptsLibravatar Lars Schneider1-80/+8
Most of the Travis CI commands are in the '.travis.yml'. The yml format does not support functions and therefore code duplication is necessary to run commands across all builds. To fix this, add a library for common CI functions. Move all Travis CI code into dedicated scripts and make them call the library first. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-23Merge branch 'ab/fix-poison-tests'Libravatar Junio C Hamano1-3/+10
Update tests to pass under GETTEXT_POISON (a mechanism to ensure that output strings that should not be translated are not translated by mistake), and tell TravisCI to run them. * ab/fix-poison-tests: travis-ci: add job to run tests with GETTEXT_POISON travis-ci: setup "prove cache" in "script" step tests: fix tests broken under GETTEXT_POISON=YesPlease
2017-05-16Merge branch 'ls/travis-doc-asciidoctor'Libravatar Junio C Hamano1-2/+3
Travis CI gained a task to format the documentation with both AsciiDoc and AsciiDoctor. * ls/travis-doc-asciidoctor: travis-ci: check AsciiDoc/AsciiDoctor stderr output travis-ci: unset compiler for jobs that do not need one travis-ci: parallelize documentation build travis-ci: build documentation with AsciiDoc and Asciidoctor
2017-05-11travis-ci: add job to run tests with GETTEXT_POISONLibravatar Lars Schneider1-0/+5
Add a job to run Git tests with GETTEXT_POISON. In this job we don't run the git-p4, git-svn, and HTTPD tests to save resources/time (those tests are already executed in other jobs). Since we don't run these tests, we can also skip the "before_install" step (which would install the necessary dependencies) with an empty override. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-11travis-ci: setup "prove cache" in "script" stepLibravatar Lars Schneider1-3/+5
The command that made the "prove cache" persistent across builds was executed in the "before_install" step. Consequently, every job that wanted to make use of the cache had to run this step. The "prove cache" is only used in the "script" step for the "make test" command. Therefore, we should configure the "prove cache" in this step. This change is useful for a subsequent patch that adds a job which does not need the "before_install" step but wants to run the "script" step to execute the tests. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-01Merge branch 'ls/travis-stricter-linux32-builds'Libravatar Junio C Hamano1-0/+1
32-bit Linux build on Travis CI uses stricter compilation options. * ls/travis-stricter-linux32-builds: travis-ci: set DEVELOPER knob for Linux32 build
2017-04-27travis-ci: set DEVELOPER knob for Linux32 buildLibravatar Lars Schneider1-0/+1
The Linux32 build was not build with our strict compiler settings (e.g. warnings as errors). Fix this by passing the DEVELOPER environment variable to the docker container. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-26Merge branch 'ls/travis-coccicheck'Libravatar Junio C Hamano1-0/+12
Travis CI learns to run coccicheck. * ls/travis-coccicheck: travis-ci: add static analysis build job to run coccicheck
2017-04-16travis-ci: add static analysis build job to run coccicheckLibravatar Lars Schneider1-0/+12
Add a dedicated build job for static analysis. As a starter we only run coccicheck but in the future we could run Clang Static Analyzer or similar tools, too. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16travis-ci: unset compiler for jobs that do not need oneLibravatar Lars Schneider1-1/+2
TravisCI does not need to setup any compiler for the documentation build. Clear the value to fix this. The Linux32 build job does not define the compiler but it inherits the value from the base job. Since it does not need the compiler either because the build runs inside a Docker container we should clear this, too. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16travis-ci: build documentation with AsciiDoc and AsciidoctorLibravatar Lars Schneider1-1/+1
ec3366e introduced a knob to enable the use of Asciidoctor in addition to AsciiDoc. Build the documentation on TravisCI with this knob to reduce the likeliness of breaking Asciidoctor support in the future. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-28travis-ci: build and test Git on WindowsLibravatar Lars Schneider1-0/+11
Most Git developers work on Linux and they have no way to know if their changes would break the Git for Windows build. Let's fix that by adding a job to TravisCI that builds and tests Git on Windows. Unfortunately, TravisCI does not support Windows. Therefore, we did the following: * Johannes Schindelin set up a Visual Studio Team Services build sponsored by Microsoft and made it accessible via an Azure Function that speaks a super-simple API. We made TravisCI use this API to trigger a build, wait until its completion, and print the build and test results. * A Windows build and test run takes up to 3h and TravisCI has a timeout after 50min for Open Source projects. Since the TravisCI job does not use heavy CPU/memory/etc. resources, the friendly TravisCI folks extended the job timeout for git/git to 3h. Things, that would need to be done: * Someone with write access to https://travis-ci.org/git/git would need to add the secret token as "GFW_CI_TOKEN" variable in the TravisCI repository setting [1]. Afterwards the build should just work. Things, that might need to be done: * The Windows box can only process a single build at a time. A second Windows build would need to wait until the first finishes. This waiting time and the build time after the wait could exceed the 3h threshold. If this is a problem, then it is likely to happen every day as usually multiple branches are pushed at the same time (pu/next/ master/maint). I cannot test this as my TravisCI account has the 50min timeout. One solution could be to limit the number of concurrent TravisCI jobs [2]. [1] https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings [2] https://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-06Travis: also test on 32-bit LinuxLibravatar Johannes Schindelin1-0/+21
When Git v2.9.1 was released, it had a bug that showed only on Windows and on 32-bit systems: our assumption that `unsigned long` can hold 64-bit values turned out to be wrong. This could have been caught earlier if we had a Continuous Testing set up that includes a build and test run on 32-bit Linux. Let's do this (and take care of the Windows build later). This patch asks Travis CI to install a Docker image with 32-bit libraries and then goes on to build and test Git using this 32-bit setup. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23travis-ci: fix Perforce install on macOSLibravatar Lars Schneider1-10/+2
The `perforce` and `perforce-server` package were moved from brew [1][2] to cask [3]. Teach TravisCI the new location. Perforce updates their binaries without version bumps. That made the brew install (legitimately!) fail due to checksum mismatches. The workaround is not necessary anymore as Cask [4] allows to disable the checksum test for individual formulas. [1] https://github.com/Homebrew/homebrew-binary/commit/1394e42de04d07445f82f9512627e864ff4ca4c6 [2] https://github.com/Homebrew/homebrew-binary/commit/f8da22d6b8dbcfcfdb2dfa9ac1a5e5d8e05aac2b [3] https://github.com/caskroom/homebrew-cask/pull/29180 [4] https://caskroom.github.io/ Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05travis-ci: update P4 to 16.2 and GitLFS to 1.5.2 in Linux buildLibravatar Lars Schneider1-2/+2
Update Travis-CI dependencies to the latest available versions in Linux build. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-11Merge branch 'ls/macos-update'Libravatar Junio C Hamano1-1/+2
Portability update and workaround for builds on recent Mac OS X. * ls/macos-update: travis-ci: disable GIT_TEST_HTTPD for macOS Makefile: set NO_OPENSSL on macOS by default
2016-11-10travis-ci: disable GIT_TEST_HTTPD for macOSLibravatar Lars Schneider1-1/+2
TravisCI changed their default macOS image from 10.10 to 10.11 [1]. Unfortunately the HTTPD tests do not run out of the box using the pre-installed Apache web server anymore. Therefore we enable these tests only for Linux and disable them for macOS. [1] https://blog.travis-ci.com/2016-10-04-osx-73-default-image-live/ Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Merge branch 'jk/tap-verbose-fix'Libravatar Junio C Hamano1-1/+1
The Travis CI configuration we ship ran the tests with --verbose option but this risks non-TAP output that happens to be "ok" to be misinterpreted as TAP signalling a test that passed. This resulted in unnecessary failure. This has been corrected by introducing a new mode to run our tests in the test harness to send the verbose output separately to the log file. * jk/tap-verbose-fix: test-lib: bail out when "-v" used under "prove" travis: use --verbose-log test option test-lib: add --verbose-log option test-lib: handle TEST_OUTPUT_DIRECTORY with spaces
2016-10-21travis: use --verbose-log test optionLibravatar Jeff King1-1/+1
Because we run the tests via "prove", the output from "--verbose" may interfere with our TAP output. Using "--verbose-log" solves this while letting us retain our on-disk log. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'ls/travis-homebrew-path-fix'Libravatar Junio C Hamano1-1/+1
The procedure to build Git on Mac OS X for Travis CI hardcoded the internal directory structure we assumed HomeBrew uses, which was a no-no. The procedure has been updated to ask HomeBrew things we need to know to fix this. * ls/travis-homebrew-path-fix: travis-ci: ask homebrew for its path instead of hardcoding it
2016-09-22travis-ci: ask homebrew for its path instead of hardcoding itLibravatar Lars Schneider1-1/+1
The TravisCI macOS build is broken because homebrew (a macOS dependency manager) changed its internal directory structure [1]. This is a problem because we modify the Perforce dependencies in the homebrew repository before installing them. Fix it by asking homebrew for its path instead of hardcoding it. [1] https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547 Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10Merge branch 'ls/travis-enable-httpd-tests' into maintLibravatar Junio C Hamano1-0/+2
Allow http daemon tests in Travis CI tests. * ls/travis-enable-httpd-tests: travis-ci: enable web server tests t55xx on Linux
2016-07-25Merge branch 'ls/travis-enable-httpd-tests'Libravatar Junio C Hamano1-0/+2
Allow http daemon tests in Travis CI tests. * ls/travis-enable-httpd-tests: travis-ci: enable web server tests t55xx on Linux
2016-07-12travis-ci: enable web server tests t55xx on LinuxLibravatar Lars Schneider1-0/+2
Install the "apache" package to run the Git web server tests on Travis-CI Linux build machines. The tests are already executed on OS X build machines since the apache web server is installed by default. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-21perf: accommodate for MacOSXLibravatar Johannes Schindelin1-0/+2
As this developer has no access to MacOSX developer setups anymore, Travis becomes the best bet to run performance tests on that OS. However, on MacOSX /usr/bin/time is that good old BSD executable that no Linux user cares about, as demonstrated by the perf-lib.sh's use of GNU-ish extensions. And by the hard-coded path. Let's just work around this issue by using gtime on MacOSX, the Homebrew-provided GNU implementation onto which pretty much every MacOSX power user falls back anyway. To help other developers use Travis to run performance tests on MacOSX, the .travis.yml file now sports a commented-out line that installs GNU time via Homebrew. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'ls/travis-build-doc' into maintLibravatar Junio C Hamano1-0/+15
CI test was taught to build documentation pages. * ls/travis-build-doc: travis-ci: build documentation
2016-05-22travis-ci: enable Git SVN tests t91xx on LinuxLibravatar Lars Schneider1-0/+1
Install the "git-svn" package to make the Perl SVN libraries available to the Git SVN tests on Travis-CI Linux build machines. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Eric Wong <e@80x24.org>
2016-05-17Merge branch 'ls/travis-build-doc'Libravatar Junio C Hamano1-0/+15
CI test was taught to build documentation pages. * ls/travis-build-doc: travis-ci: build documentation
2016-05-10travis-ci: build documentationLibravatar Lars Schneider1-0/+15
Build documentation as separate Travis CI job to check for documentation errors. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-28travis-ci: express Linux/OS X dependency versions more clearlyLibravatar Lars Schneider1-7/+10
The Git Travis CI OSX build always installs the latest versions of Git LFS and Perforce via brew and the Linux build installs fixed versions. Consequently new LFS/Perforce versions can break the OS X build even if there is no change in Git. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-19travis-ci: update Git-LFS and P4 to the latest versionLibravatar Lars Schneider1-2/+2
Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25add DEVELOPER makefile knob to check for acknowledged warningsLibravatar Lars Schneider1-1/+1
We assume Git developers have a reasonably modern compiler and recommend them to enable the DEVELOPER makefile knob to ensure their patches are clear of all compiler warnings the Git core project cares about. Enable the DEVELOPER makefile knob in the Travis-CI build. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26travis-ci: explicity use container-based infrastructureLibravatar Lars Schneider1-0/+2
Set `sudo: false` to explicitly use the (faster) container-based infrastructure for the Travis-CI Linux build. More info: https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26travis-ci: run previously failed tests first, then slowest to fastestLibravatar Lars Schneider1-1/+7
The Travis-CI machines are in a clean state in the beginning of every run (transient by default). Use the Travis-CI cache feature to make the prove state persistent across consecutive Travis-CI runs on the same branch. This allows to run previously failed tests first and run remaining tests in slowest to fastest order. As a result it is less likely that Travis-CI needs to wait for a single test at the end which speeds up the test suite execution by ~2 min. Travis-CI can only cache entire directories. Prove stores the .prove file always in the t/ directory but we don't want to cache the entire t/ directory. Therefore we create a symlink from $HOME/travis-cache/.prove to t/.prove and cache the $HOME/travis-cache directory. Unfortunately the cache feature is only available (for free) on the Travis-CI Linux environment. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-28Add Travis CI supportLibravatar Lars Schneider1-0/+91
The tests are currently executed on "Ubuntu 12.04 LTS Server Edition 64 bit" and on "OS X Mavericks" using gcc and clang. Perforce and Git-LFS are installed and therefore available for the respective tests. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net>