Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Switch Travis to Trusty #7920
I worked with Travis to get the cache flag on my personal repo for testing, and I'm happy to report that all works great (after a day of churning builds).
For some background: Travis has enabled caching for their new infrastructure, but the feature is brand new and not yet generally available. For now it requires a special flag (set on their end) on your repo. Once they're satisfied with its stability, the flag will be granted to everyone. Note that the flag comes with the caveat of invalidating all current caches. That's not a problem for us, other than slowing things down for a few hours. I was primarily worried about unintended side-effects of opting in, so I added it on my own repo for testing before requesting it here.
If there's no reason to delay our move, I'll request the flag for this repo tomorrow (4/21).
Once that's take care of, we can merge this for Trusty goodness. On the day that Xenial is scheduled to be released :p.
Next step is c++11, which should be painless to enable now.
Note that the build failed because we currently have a (different) special flag on our repo that force-routes us to the legacy infrastructure for caching. This change will disable that in favor of the new testing flag.
(It may sound convoluted, but this change moves us one step closer towards being a normal repo. Once the caching feature is out of beta, there will be nothing special about us.)
@MarcoFalke Just for the sake of being future-proof. It only uses the python2 one at the moment, but I believe the (your?) intention is to move the rpc tests to python3. Just doing python2 for now is fine by me if that's what you'd prefer. I was just saving some future head-scratching when builds fail after the switch.
Edit: Looking at the diff, I now see why you asked. Python was a headache when testing the migration from precise->trusty. I had a theory at one point that python3 was being forced for the rpc tests, which obviously turned out to not be the case. But I left it there since that's where we're headed.
Ok, finally all green and cache-enabled.
I disabled a few qt builds because they seem to take longer on this infrastructure than before. We can investigate and turn them back on asap.
For now, until this is merged, PRs will be unusually slow, so it's probably best to go ahead with this now and work through the regressions.
To expand on the "PRs will be unusually slow" bit above:
In removing the special bits from our repo, all caches have been invalidated. In theory, precise caches will be regenerated for subsequent PRs, but I'm nervous about that actually happening seamlessly on the deprecated platform.
Even if it does work without issue, PRs will be slow until something is pushed into master. When a PR is created, the build cache is taken from its source branch (master), and copied into the PR. From there, the PR updates its own cache with each update.
Right now we have no master cache, and no PR caches. So until there's something to pull from master, each PR will be rebuilding from scratch. Also, once we do pull the trigger on this, it will essentially invalidate all caches again, because all dependencies will be rebuilt for the new toolchains.
tl;dr: Need to push something into master asap to avoid slow builds all day. May as well push this one, to avoid a repeat.