-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
CI: switch travis to sudo-required #22986
Conversation
Looks like the sudo-enabled workers pull from a different cache than the sudo-disabled workers, so this is having to build deps from scratch. That's not the end of the world if it actually works as fast as Travis used to, it had been able to build deps in roughly 35 minutes then get to the end of the tests in just under 2 hours total. If this can't match that, we might be in a lot of trouble and need to really get on Travis' case or seek out alternatives and stop paying them for a service that isn't working for us any more. |
This appears to not have fixed the performance problem with travis. |
d041950
to
5e6782f
Compare
Travis support suggested that they have changed some settings which may make this better. |
It does not seem to have fixed anything since the build took 2 hours and didn't complete. The network setup on the premium VMs has borked UDP too (incorrectly configured loopback interface). |
It was quite a bit faster actually. Much of the time was spent building deps to populate the cache, which wouldn't have to be done on most builds. It runs on GCE and doesn't support ipv6 so we'd have to disable that socket test like we're doing on Circle. We can let Travis know this performed like their normal VM's used to, but for our purposes I think it would be better to get doc deployment working from Circle, then disable Linux builds on Travis. |
No, I've said many times that for the next several months we should double up on CI so that we always have some CI system that's working. We cannot afford to put all our eggs in one basket. |
I agree that until 1.0 is out, let's just keep travis. If travis solves our issues, great. If not, we find an alternative. |
What isn't working about Circle? Turning Linux Travis builds back on if we decide we want them again isn't exactly difficult, and in the meantime we'd have a faster turnaround on mac builds where Travis is currently our best option. We can find out what it would require from Travis to keep the premium VM's indefinitely. There might be a way involving running some of the tests inside a docker container that could get the socket tests to pass. ref MariadeAnton#1 |
The point is that keep circle and travis both running. There is no need to disable anything on travis until 1.0. Worst case it keeps failing and we can ignore it. |
5e6782f
to
286a2bc
Compare
(cherry picked from commit 0189574)
(cherry picked from commit 0189574)
(cherry picked from commit 0189574)
Recommend by Travis support to try for better performance of our builds.