kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Johannes Schindelin	87b68db3ac	ci: fix the `jobname` of the `GETTEXT_POISON` job In `6cdccfce1e` (i18n: make GETTEXT_POISON a runtime option, 2018-11-08), the `jobname` was adjusted to have the `GIT_TEST_` prefix, but that prefix makes no sense in this context. Co-authored-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Đoàn Trần Công Danh	e0f8690dee	travis: build and test on Linux with musl libc and busybox Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Đoàn Trần Công Danh	5a33f541dd	ci: refactor docker runner script We will support alpine check in docker later in this series. While we're at it, tell people to run as root in podman, if podman is used as drop-in replacement for docker, because podman will map host-user to container's root, therefore, mapping their permission. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
SZEDER Gábor	fb9d7431cf	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>	6 years ago
Johannes Schindelin	50b206371d	travis: remove the hack to build the Windows job on Azure Pipelines 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>	6 years ago
SZEDER Gábor	2000ac9fbf	travis-ci: switch to Xcode 10.1 macOS image 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>	6 years ago
Ævar Arnfjörð Bjarmason	6cdccfce1e	i18n: make GETTEXT_POISON a runtime option 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>	6 years ago
SZEDER Gábor	0f0c51181d	travis-ci: install packages in 'ci/install-dependencies.sh' 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>	6 years ago
Sebastian Staudt	32ee384be8	travis-ci: no longer use containers Travis CI will soon deprecate the container-based infrastructure enabled by `sudo: false` in `ce59dffb34`. 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>	6 years ago
Nguyễn Thái Ngọc Duy	37fa4b3c78	travis-ci: run gcc-8 on linux-gcc jobs 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>	7 years ago
SZEDER Gábor	3c93b82920	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>	7 years ago
SZEDER Gábor	2c9a2dd0cd	travis-ci: don't install default addon packages for the 32 bit Linux build 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>	7 years ago
SZEDER Gábor	e3371e9260	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>	7 years ago
SZEDER Gábor	bf427a9451	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>	7 years ago
SZEDER Gábor	c2154953b8	travis-ci: don't build Git for the static analysis job 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>	7 years ago
Lars Schneider	657343a602	travis-ci: move Travis CI code into dedicated scripts 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>	7 years ago
Lars Schneider	b8e188f6f5	travis-ci: add job to run tests with GETTEXT_POISON 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>	8 years ago
Lars Schneider	3ae72a3aca	travis-ci: setup "prove cache" in "script" step 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>	8 years ago
Lars Schneider	dcc3e7f5fd	travis-ci: set DEVELOPER knob for Linux32 build 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>	8 years ago
Lars Schneider	d8245bb3fd	travis-ci: add static analysis build job to run coccicheck 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>	8 years ago
Lars Schneider	912b0ab149	travis-ci: unset compiler for jobs that do not need one 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>	8 years ago
Lars Schneider	159e6010c2	travis-ci: build documentation with AsciiDoc and Asciidoctor `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>	8 years ago
Lars Schneider	029aeeed55	travis-ci: build and test Git on Windows 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>	8 years ago
Johannes Schindelin	88dedd5e72	Travis: also test on 32-bit Linux 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>	8 years ago
Lars Schneider	672f51cb83	travis-ci: fix Perforce install on macOS 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] `1394e42de0` [2] `f8da22d6b8` [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>	8 years ago
Lars Schneider	5f703e8f02	travis-ci: update P4 to 16.2 and GitLFS to 1.5.2 in Linux build 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>	8 years ago
Lars Schneider	a296bc0132	travis-ci: disable GIT_TEST_HTTPD for macOS 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>	8 years ago
Jeff King	041c72de10	travis: use --verbose-log test option 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>	8 years ago
Lars Schneider	f86f49bee9	travis-ci: ask homebrew for its path instead of hardcoding it 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] `0a09ae30f8` Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Lars Schneider	d9d1426830	travis-ci: enable web server tests t55xx on Linux 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>	9 years ago
Johannes Schindelin	e3efa94be9	perf: accommodate for MacOSX 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>	9 years ago
Lars Schneider	e7e9f5e7a1	travis-ci: enable Git SVN tests t91xx on Linux 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>	9 years ago
Lars Schneider	b98712b9aa	travis-ci: build documentation 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>	9 years ago
Lars Schneider	3d319f2c63	travis-ci: express Linux/OS X dependency versions more clearly 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>	9 years ago
Lars Schneider	31f3c86b43	travis-ci: update Git-LFS and P4 to the latest version Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Lars Schneider	658df95a4a	add DEVELOPER makefile knob to check for acknowledged warnings 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>	9 years ago
Lars Schneider	ce59dffb34	travis-ci: explicity use container-based infrastructure 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>	9 years ago
Lars Schneider	6272ed3194	travis-ci: run previously failed tests first, then slowest to fastest 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>	9 years ago
Lars Schneider	522354d70f	Add Travis CI support 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>	9 years ago

1 2

51 Commits (bea866587c7639fac4146cadfdee30fcc9815c36)