Commit Graph

28 Commits

Author SHA1 Message Date
Eduard Burtescu 0268cfaa1f Set `RUST_BACKTRACE=1` on travis to be more helpful. 2016-11-12 14:30:28 +02:00
Alex Crichton 008cc2d999 Move all Linux/OSX CI infastructure to Travis
This commit configures our `.travis.yml` to test the full suite of tests we have
on Buildbot right now. A whole mess of docker images are added to the `src/ci`
directory which represent all the build environments for each configuration.
Each of these environments is then configured in `.travis.yml` to run on the
auto branch.

Note that the full matrix of tests aren't intended to be run on all PRs.
Instead, we continue to run only one entry in the matrix, forcing all others to
finish quickly. Only the `auto` branch should run the full matrix of builds.

Also note that the infrastructure hasn't quite been allocated yet to the
rust-lang/rust repository, so everything is disabled for now except for the one
build that happens on PRs. Once that infrastructure is allocated though we can
enable this and let it fly!

Notable modifications from the current test suite today:

* Android tests are run in rustbuild instead of the makefiles, for whatever
  reason I couldn't get the makefiles to work on Travis.
* A debuginfo test was updated to work with the current version of the Android
  NDK.
* Some dependencies in `mk/tests.mk` were fixed to allow running tests in
  parallel.
2016-11-11 07:36:40 -08:00
Alex Crichton 31a8638e5e rustbuild: Tweak for vendored dependencies
A few changes are included here:

* The `winapi` and `url` dependencies were dropped. The source code for these
  projects is pretty weighty, and we're about to vendor them, so let's not
  commit to that intake just yet. If necessary we can vendor them later but for
  now it shouldn't be necessary.

* The `--frozen` flag is now always passed to Cargo, obviating the need for
  tidy's `cargo_lock` check.

* Tidy was updated to not check the vendor directory

Closes #34687
2016-11-08 07:32:05 -08:00
Corey Farwell c8c6d2c732 Use quieter test output when running tests on Travis CI.
Fixes https://github.com/rust-lang/rust/issues/36788.
2016-10-30 17:31:17 -04:00
Corey Farwell 3a96fe3275 Transition Travis CI to use rustbuild. 2016-09-02 12:48:55 -04:00
Stefan Schindler ca259666a5 Reduce git clone --depth from 50 to 1 2016-07-28 11:48:43 +02:00
Seo Sanghyeon b1651fb4d2 Use Docker for Travis 2016-06-03 11:44:30 +09:00
arcnmx 1181ca4b51 Use Travis trusty infrastructure 2015-10-19 18:31:02 -04:00
Alex Crichton 27dd6dd3db 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-29 16:56:35 -07:00
Huon Wilson 91a9260a16 Run tidy by itself on travis.
It is very difficult to find tidy problems in the midst of the output of
the LLVM/jemalloc/etc. build, and travis is great for the former, so
lets remove that problem.
2015-08-28 22:59:00 -07:00
Alexis Beingessner b0acde7370 make travis extreme 2015-07-24 09:45:34 -07:00
Alexis Beingessner e8a03285b7 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-15 10:48:50 -07:00
Matthew Astley 512b105b15 point to buildbot
Since 7b6ecc00
2015-06-11 19:57:16 +01:00
dan@daramos.com 637f2c5ea4 Allow travis to use newer-faster infrastructure for building. http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/ 2015-01-01 02:00:29 -05:00
Alex Crichton 7b6ecc009c travis: Fix for real this time
I ended up botching the merge when making the rollup, and the fix was to just
not configure LLVM all via --llvm-root with a nonexistent path.
2014-10-03 07:25:10 -07:00
Alex Crichton d911936dbd Merge branch 'travis' into rollup
Conflicts:
	.travis.yml
2014-10-02 21:02:36 -07:00
Alex Crichton 9ac804ecab travis: Stop building and testing rust
Instead, only run `make tidy`. The tidy script can run quite quickly, and it's
super annoying to run tests for 50 minutes only to have bors fail with a
"trailing whitespace" error.
2014-10-02 15:11:52 -07:00
Alex Crichton cc9347a902 travis: Stop building and testing rust
Instead, only run `make tidy`. The tidy script can run quite quickly, and it's
super annoying to run tests for 50 minutes only to have bors fail with a
"trailing whitespace" error.
2014-10-02 13:50:43 -07:00
Alex Crichton 9af1b0e5e1 travis: Move from travis_wait to time-passes
It's looking like we're still timing out all over the place with travis_wait
because the entire `make -j4 rustc-stage1` command is taking too long. Instead,
achieve roughly the same idea by just having `-Z time-passes` printing
information. We shouldn't have a pass that takes longer than 10 minutes in
isolation.
2014-07-01 20:21:16 -07:00
Alex Crichton 8c057984c6 travis: Don't use a local jemalloc
Turns out they don't have the `je_` prefix, so we can't use the system-installed
jemalloc.
2014-06-12 16:12:37 -07:00
Alex Crichton 46014c7b14 travis: Use a pre-installed jemalloc 2014-06-12 00:28:01 -07:00
Alex Crichton bc17897116 travis: Prevent timeouts with travis_wait
The most frequent failure for our travis builds is running into the timeout
limits when building the compiler itself. Building librustc takes a very long
amount of time, often hitting the 10 minutes with no output threshold that
travis imposes on us.

This commit switches the relevant `make` step to being wrapped in the
`travis_wait` command [1]. This command will print something once a minute so as
to not time out a build.

This will hopefully enable us to have fewer flaky builds on travis!

[1]: http://docs.travis-ci.com/user/build-timeouts/
2014-06-04 17:16:37 -07:00
Flavio Percoco 3c4edff9b5 Let travis check docs for stage1 2014-03-20 10:20:08 +01:00
Alex Crichton 37b3a60b78 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 00:25:19 -08:00
Luca Bruno 357cadf722 travis: remove manually added RUSTFLAGS
Indirect dependencies should now be picked up through the
autogenerated llvmdeps.rs instead.

Signed-off-by: Luca Bruno <lucab@debian.org>
2014-03-02 20:02:42 +01:00
Alex Crichton bbdaf01a5a travis: Use LLVM 3.3 from the official repos
We can be certain that this version of LLVM will not be changing, so we don't
have to worry about API drift over time.
2014-02-26 15:22:50 -08:00
Alex Crichton a7b1d65080 Run the travis build as one large command
It appears that travis doesn't stop running script commands after the first one
fails (see https://github.com/travis-ci/travis-ci/issues/1066), so chain all our
commands together with && for now.
2014-02-24 21:22:27 -08:00
Alex Crichton 5bb204ffdb 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 21:43:25 -08:00