Commit Graph

105 Commits

Author SHA1 Message Date
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