squiid/rust
1
0
Fork 0
Code Issues Pull requests Projects Activity
rust/.travis.yml

65 lines
2.5 KiB
YAML
Raw Normal View History

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-21 00:37:44 +01:00
# Use something that's not 'ruby' so we don't set up things like
# RVM/bundler/ruby and whatnot. Right now 'rust' isn't a language on travis and
# it treats unknown languages as ruby-like I believe.
language: c
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-27 00:04:18 +01:00
# Before we start doing anything, install a stock LLVM
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-21 00:37:44 +01:00
install:
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 06:17:15 +01:00
- sudo sh -c "echo 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise-3.4 main' >> /etc/apt/sources.list"
- sudo sh -c "echo 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise main' >> /etc/apt/sources.list"
- sudo sh -c "echo 'deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main' >> /etc/apt/sources.list"
- wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add -
- sudo apt-get update -qq
- sudo apt-get install -qq --force-yes -y llvm-$LLVM_VERSION
llvm-${LLVM_VERSION}-dev clang-$LLVM_VERSION lldb-$LLVM_VERSION
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-21 00:37:44 +01: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 06:17:15 +01:00
# All of the llvm tools are suffixed with "-$VERS" which we don't want, so
# symlink them all into a local directory and just use that
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-21 00:37:44 +01:00
#
# FIXME: this shouldn't update the src/llvm sub-repo, that takes about a minute
# it's gotta download so much stuff.
before_script:
- mkdir -p local-llvm/bin
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 06:17:15 +01:00
- ln -nsf /usr/bin/llvm-config-$LLVM_VERSION local-llvm/bin/llvm-config
- ln -nsf /usr/bin/llvm-mc-$LLVM_VERSION local-llvm/bin/llvm-mc
- ln -nsf /usr/bin/llvm-as-$LLVM_VERSION local-llvm/bin/llvm-as
- ln -nsf /usr/bin/llvm-dis-$LLVM_VERSION local-llvm/bin/llvm-dis
- ln -nsf /usr/bin/llc-$LLVM_VERSION local-llvm/bin/llc
- ln -nsf /usr/include/llvm-$LLVM_VERSION local-llvm/include
travis: Use a pre-installed jemalloc
2014-06-07 08:55:05 +02:00
- ./configure --disable-optimize-tests --llvm-root=`pwd`/local-llvm
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-13 01:12:37 +02:00
--enable-fast-make --enable-clang
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-21 00:37:44 +01:00
# Tidy everything up first, then build a few things, and then run a few tests.
# Note that this is meant to run in a "fairly small" amount of time, so this
# isn't exhaustive at all.
#
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 08:23:08 +01:00
# As a result of https://github.com/travis-ci/travis-ci/issues/1066, we run
# everything in one large command instead of multiple commands.
script: |
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 06:17:15 +01:00
if [[ $TRAVIS_PULL_REQUEST != 'false' ]]; then
if [[ $LLVM_VERSION != '3.4' ]]; then exit 0; fi
fi &&
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 08:23:08 +01:00
make tidy &&
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 21:00:42 +02:00
travis_wait make -j4 rustc-stage1 &&
Let travis check docs for stage1
2014-03-20 10:20:08 +01:00
make check-stage1-std check-stage1-rpass check-stage1-cfail check-stage1-rfail check-stage1-doc
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-21 00:37:44 +01:00
env:
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 06:17:15 +01:00
global:
- NO_BENCH=1
matrix:
- LLVM_VERSION=3.3
- LLVM_VERSION=3.4
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-21 00:37:44 +01:00
# We track this ourselves, and in theory we don't have to update the LLVM repo
# (but sadly we do right now anyway).
git:
submodules: false
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 06:17:15 +01:00
notifications:
email: false
branches:
only:
- master
Reference in a new issue Copy permalink