mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0f491bee69
rust/.travis.yml

47 lines
1.3 KiB
YAML
Raw Normal View History

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-13 19:29:01 -05:00
# ccache support is disabled unless your language is a C-derivative. However
# `language: C` unconditionally sets `CC=compiler`. If we just set it in our
# `env` it will be overwritten by the default (gcc 4.6).
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 17:37:44 -06:00
language: c
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-13 19:29:01 -05:00
compiler: /usr/bin/gcc-4.7
cache: ccache
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 01:00:29 -06:00
sudo: false
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 17:37:44 -06:00
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:50:43 -05:00
# The test suite is in general way too stressful for travis, especially in
# terms of time limit and reliability. In the past we've tried to scale things
# back to only build the stage1 compiler and run a subset of tests, but this
# didn't end up panning out very well.
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 17:37:44 -06:00
#
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-13 19:29:01 -05:00
# As a result, we're just using travis to run `make tidy` and *only* build
# stage1 but *not* test it for now (a strict subset of the bootstrap). This will
# catch "obvious" errors like style or not even compiling.
#
# We need gcc4.7 or higher to build LLVM, and travis (well, Ubuntu 12.04)
# currently ships with 4.6. Gotta download our own.
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 17:37:44 -06:00
before_script:
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-13 19:29:01 -05:00
- ./configure --enable-ccache
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:50:43 -05:00
script:
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-29 00:59:00 -05:00
- make tidy && make check -j4
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-13 19:29:01 -05:00
env:
- CXX=/usr/bin/g++-4.7
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- gcc-4.7
- g++-4.7
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-05 23:17:15 -06:00
point to buildbot Since 7b6ecc00
2015-06-11 04:26:19 -05: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-05 23:17:15 -06:00
notifications:
email: false
branches:
only:
- master
Reference in New Issue Copy Permalink