khmer
khmer copied to clipboard
dib-lab
Look into caching OS X Miniconda install on Travis CI
Travis CI allows you to cache components/directories created as part of your build. This won't improve the availability of OS X VMs, but once an OS X VM is available this should speed up the build significantly.
Also, is there any reason to run extra tests/builds on OS X vs Linux? Since we always seem to be waiting on OS X VMs, perhaps we could move these to one of the Linux VMs?
We spend about 3minutes on installing things on OSX.
The travis docs suggest not caching stuff which is dominated by "downloading stuff from the network" as the cache tarball comes over the network as well.
From a quick browse of the logs it seems we don't really compile much stuff, which suggests we are waiting on the network. I will take a look how complex it would get to cache the various different directories.
We use the OSX build as the reference for coverage and formatting. make test takes 155s. To compute the coverage we recompile things and re-execute the tests (120s). Can we combine these two steps?
(The availability of OSX nodes is pretty shocking, especially during California day time)
Yeah, I think I was off base with my initial comment about caching. The Miniconda install is a relatively small contributor to the long runtime. I think it's mostly the multiple builds. Not sure why everything is recompiled from scratch to compute coverage, etc. Now I'm just wondering why OS X is used as reference, and whether it could save us some work-hours backlogging if we moved this to one of the Linux VMs.
On Wed, Nov 16, 2016 at 09:38:27AM -0800, Daniel Standage wrote:
Yeah, I think I was off base with my initial comment about caching. The Miniconda install is a relatively small contributor to the long runtime. I think it's mostly the multiple builds. Not sure why everything is recompiled from scratch to compute coverage, etc. Now I'm just wondering why OS X is used as reference, and whether it could save us some work-hours backlogging if we moved this to one of the Linux VMs.
+1
Now I'm just wondering why OS X is used as reference
More or less arbitrary. The reason that tipped it was that the version of make format on linux and on OSX disagree on what the correct format should be. So I guessed that most people use OSX locally -> make osx the reference. The way forward would be to figure out how to install the OSX/newer version of the formatting tool on debian (I spent some time on this when we moved to travis but gave up, my debian-fu was not strong enough).
Still don't know howto get a newer version of astyle on trusty. What do people think about switching to clang-format? I prefer it as it is more modern and has the oumph of Google behind it in terms of keeping it working, etc.
We need to rebuild to get coverage results because you need to compile with different arguments to augment the code to generate the coverage.
Overall I think waiting 5min or 10min for travis to do its thing isn't that big a deal and I'd be -0 on investing effort to speed things up on that time scale. What is more annoying is OSX which takes hours. I'm not sure I like the idea of making OSX optional because that will invariably lead to something in master being broken because stuff got merged without waiting for OSX. Which means waiting for OSX always...kinda catch 22. :-/
What do people think about switching to clang-format
My experience with clang-format, though limited, has been positive. I have no experience with astyle. I'd say if it's an easy switch and makes our lives easier, it should be pretty easy to justify to our fearless leader.
Before we go too much off topic discussing the finer points of what colour our source code formatter should be: the problem we wanted to solve is that travis takes too long right? I had hoped that we could get all the information that is needed to decide on the fate of a PR without waiting for the OSX build.
I found how to exclude a whole CI provider from codecov but because OSX and linux are both travis that doesn't help. The next level up would be to move our linux builds to AppVeyor and tell codecov not to wait for travis when calculating the coverage. Or we give up on OSX builds. Or reactivate jenkins for the OSX build. Don't really like either option to be honest. Ideas?
I'm -1 on any big changes for the time being. Yes, the OS X Travis builds are the big pain point right now. It's not that the build itself takes too long, but often we have to wait 45min+ for the build to even start. My thought was that anything we could do to make the OS X build quicker, the better. But of course, we have to balance this against how much effort it will take and the time savings we gain. Since the time savings in the build will be minimal compared to the wait times, we shouldn't expend too much effort.
I think I asked this before but: can we pay Travis for better service? ISTR it was expensive tho. Anyway, could be a solution.
https://www.traviscistatus.com/ only shows you how backlogged they are for unpaid OSX instances, so hard to judge how backlogged they are for paid OSX instances. We could use the free trial on https://travis-ci.com/plans to see if it improves things?
Closing this, originally it was about caching which we decided wasn't worth it and then started discussing paying for faster builds -> expensive. If we want to try the free trial I think @ctb should be the one to click the buttons.