Skip to content

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

Closed
wants to merge 3 commits into from

Conversation

alexcrichton
Copy link
Member

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 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.
@emberian
Copy link
Member

This has been raised in the past, but I'm a bit uncomfortable using their (free, publically available) infrastructure so heavily...

@alexcrichton
Copy link
Member Author

I have contacted their support team to ask about this load.

@alexcrichton
Copy link
Member Author

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.

@flaper87
Copy link
Contributor

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
Copy link
Contributor

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.

@flaper87
Copy link
Contributor

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.

@brson
Copy link
Contributor

brson commented Feb 22, 2014

How do we tell Travis to start building Rust PRs?

@huonw
Copy link
Member

huonw commented Feb 22, 2014

@brson: first two steps here. Theoretically the rest is handled in this PR.

bors added a commit that referenced this pull request Feb 22, 2014
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.
@bors bors closed this Feb 22, 2014
@alexcrichton alexcrichton deleted the travis-yml branch February 22, 2014 19:12
@alexcrichton
Copy link
Member Author

@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:

  • "Build only commits with .travis.yml file" - we should turn this on in case we want to remove travis in the future
  • "Build pushes" - this should be turned off, this is what bors is responsible for
  • "Build pull requests" - this should be turned on.

I had this enabled in my own personal repo when testing, and it's already catching bugs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants