Closed MichaelXavier closed 7 years ago
@MichaelXavier I think travis_wait
works for the 10 minute output case? Does the busy-spinner do something TravisCI's provided thingy would not?
This PR build failed because we hit the 50 minute global limit on a couple of the jobs.
For an idea of the speed-gap between dedis and AWS-based CI services like CircleCI and TravisCI: http://bitemyapp.com/posts/2016-03-28-speeding-up-builds.html
I am giving this a crack right now.
https://github.com/travis-ci/travis-ci/issues/7020 christ on sale
should be g2g now, merge if you're happy. imma pass tf out now
LOL. I wasn't aware of travis_wait. That's just like me for a system to report an error with a page to read more and for me to not visit that page and come up with some much dumber solution. This seems like a better solution, thanks!
@MichaelXavier FWIW, there's a trade-off here. I halved our build time but our cache payloads are huge (~6gb per PR/branch) now, but without having done so, our builds wouldn't have been passing anyway. That means cache upload period at end of build is longer. I think it's worth it, but keep it in mind in case we have problems later.
The other thing I did to speed up our builds was turn on --fast
for build and test.
Good point. Yeah since we're not building any artifacts with our CI, may as well use --fast to speed things up slightly.
This is for #194