rust/.travis.yml

language: generic
sudo: required
services:
  - docker

# LLVM takes awhile to check out and otherwise we'll manage the submodules in
# our configure script, so disable auto submodule management.
git:
  submodules: false
  depth: 1

before_install:
  - docker build -t rust -f src/etc/Dockerfile src/etc

script:
  - docker run -v `pwd`:/build rust
    sh -c "
      ./configure --enable-rustbuild --llvm-root=/usr/lib/llvm-3.7 &&
      make tidy &&
      make check -j4
    "

# Real testing happens on http://buildbot.rust-lang.org/
#
# See https://github.com/rust-lang/rust-buildbot
#     CONTRIBUTING.md#pull-requests

notifications:
  email: false

branches:
  only:
    - master
Use Travis trusty infrastructure 2015-10-19 01:37:14 +00:00			`language: generic`
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default. 2015-09-18 17:19:23 +00:00			`sudo: required`
Use Docker for Travis 2016-06-01 15:14:22 +00:00			`services:`
			`- docker`
Add a Travis-CI configuration for the repo Travis CI provides an easy-to-use continuous integration infrastructure for github repos to use. Travis will automatically test all PRs which are opened against the rust repository, informing PR owners of the test results. I believe that this will be a very convenient piece of infrastructure as we'll be able to reduce the load on bors quite a bit. In theory all PRs opened have had the full test suite run against them, but unfortunately this is rarely the case (I'm a prime suspect). Travis will be able to provide easy and relatively quick (~30min) feedback for PRs. By ensuring fewer failures on bors, we can hopefully feed more successful jobs to bors. Overall, I expect this to be very helpful for new contributors as well as regular contributors as it's another layer of tests being run which will hopefully catch things sooner. One of the most convenient parts about using Travis is that there's very little burden in terms of maintenance, and if things go wrong we can easily turn travis completely off. Note that this is not the metric by which a PR will be merged with. Using travis will purely be another source for running tests, we will continue to gate all PRs on bors. 2014-02-20 23:37:44 +00:00
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default. 2015-09-18 17:19:23 +00:00			`# LLVM takes awhile to check out and otherwise we'll manage the submodules in`
			`# our configure script, so disable auto submodule management.`
			`git:`
			`submodules: false`
Reduce git clone --depth from 50 to 1 2016-07-28 09:48:43 +00:00			`depth: 1`
Ratchet up travis to build stage1 and our own LLVM. Tidy is still run first for failing fast on the easy stuff. To accomplish this we have travis actually persist ccache across builds. This has LLVM built within 6 minutes, and all of stage1 built within 18. Caching should work on fresh PRs (cache acquired from the master branch). Because all we persist is ccache, there is minimal danger of persisting corrupt build state. I had to mangle `configure` a bit to make --enable-ccache work when custom compilers are provide via CC and CXX. 2015-07-14 00:29:01 +00:00
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default. 2015-09-18 17:19:23 +00:00			`before_install:`
Use Docker for Travis 2016-06-01 15:14:22 +00:00			`- docker build -t rust -f src/etc/Dockerfile src/etc`
Use Travis trusty infrastructure 2015-10-19 01:37:14 +00:00
Tweak Travis to use GCE Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default. 2015-09-18 17:19:23 +00:00			`script:`
Use Docker for Travis 2016-06-01 15:14:22 +00:00			- docker run -v `pwd`:/build rust
			`sh -c "`
Transition Travis CI to use rustbuild. 2016-08-31 23:10:24 +00:00			`./configure --enable-rustbuild --llvm-root=/usr/lib/llvm-3.7 &&`
Use Docker for Travis 2016-06-01 15:14:22 +00:00			`make tidy &&`
Transition Travis CI to use rustbuild. 2016-08-31 23:10:24 +00:00			`make check -j4`
Use Docker for Travis 2016-06-01 15:14:22 +00:00			`"`
travis: Use LLVM 3.4 instead of LLVM 3.3 This version is slightly more up to date and is closer to the 3.5 that we're using. This also updates the travis config to have a build matrix which tests rust against LLVM 3.3 and 3.4. For pull requests only LLVM 3.4 is tested to reduce the load on travis. This is mostly just fluff, there's no real reason to gate rust on these results, it's more of just a nice thing to know when we break compatibility with LLVM 3.3 and 3.4 (and eventually 3.5). This turns off notifications of failed commits (which are sent out for pushes to master). 2014-03-06 05:17:15 +00:00
point to buildbot Since 7b6ecc00 2015-06-11 09:26:19 +00:00			`# Real testing happens on http://buildbot.rust-lang.org/`
			`#`
			`# See https://github.com/rust-lang/rust-buildbot`
			`# CONTRIBUTING.md#pull-requests`

travis: Use LLVM 3.4 instead of LLVM 3.3 This version is slightly more up to date and is closer to the 3.5 that we're using. This also updates the travis config to have a build matrix which tests rust against LLVM 3.3 and 3.4. For pull requests only LLVM 3.4 is tested to reduce the load on travis. This is mostly just fluff, there's no real reason to gate rust on these results, it's more of just a nice thing to know when we break compatibility with LLVM 3.3 and 3.4 (and eventually 3.5). This turns off notifications of failed commits (which are sent out for pushes to master). 2014-03-06 05:17:15 +00:00			`notifications:`
			`email: false`

			`branches:`
			`only:`
			`- master`