-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add a Travis-CI configuration for the repo #12437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is the current head of LLVM, and we can indeed build with 3.5
LLVM's tools are not contained in the local directory if --llvm-root is used by the ./configure script. This fixes the installation path to be the root provided by --llvm-root.
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.
This has been raised in the past, but I'm a bit uncomfortable using their (free, publically available) infrastructure so heavily... |
I have contacted their support team to ask about this load. |
They have responded saying that the expected load (~20 PRs a day with ~20 min builds each) is no more than what they're used to seeing. |
For the sake of history, this was raised the last time here |
script: | ||
- make tidy | ||
- RUSTFLAGS="-C link-args='-lffi -lncurses'" make -j4 rustc-stage1 | ||
- make check-stage1-std check-stage1-rpass check-stage1-cfail check-stage1-rfail |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure about running std
tests. Probably in this phase it's enough to run rpass
, cfail
and rfail
which should raise regressions if there are any.
This looks good and I'm in favor of it. If the travis team is ok with this, then I'd say we should move this forward and let it land. However, we should still build our own infrastructure and move away from travis at some point. |
How do we tell Travis to start building Rust PRs? |
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.
@brson, I don't have admin access to this repo, but if you log in and visit https://travis-ci.org/profile/mozilla, there should be a toggleable switch for this repo and we just need to flip it on now. There should also be some settings with three sliders:
I had this enabled in my own personal repo when testing, and it's already catching bugs! |
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.