-
Notifications
You must be signed in to change notification settings - Fork 881
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
Cache locally-built Homebrew bottles in OSX builds #144
Conversation
Nice! I will check this during weekend, I'm too busy today/tomorrow. |
Didn't manage to enable ccache on both Linux and OSX: in Linux, creating |
I will check this and the other pull requests / issues asap during this week, didn't found the time last weekend. |
On second thought, if |
About that deployment target param: it was a hack due to a bug in scikit-build (#110 (comment)). I think it can be moved safely to |
I'm a bit afraid of the maintenance burden this might introduce, but I think there's currently no better way to do this. And the build times are so much better with this approach. |
Github is trying to be too smart 😄 |
Closes #139.
It saves brew dependencies as they are built, measures elapsed time, and once it's high enough, fails the build but arranges for Travis cache to be saved. Then reuses the bottles on the next run. It doesn't seem that any solution currently exists, so rolled my own. Now, it does!
It also correctly detects updates and rebuilds bottles for new versions as needed.
So, basically, you need to restart jobs that print a message like "Building dependencies took too long" in Travis UI until they finish. As things are now, it takes 2 restarts to get a job to finish for the first time.
I'm not sure if Travis UI allows to restart jobs in a PR's automatic check -- in this PR, you'll be able to test this!
Travis looks for cache in the order: PR -> branch -> default branch. So building on
master
should make any other branch be able to find a cache and hopefully finish on the first try.In other news:Other changes:ccache
cache. This brings recompile times down from 20 to 8(!) minutes. Dunno how much it will help in the normal course of action 'cuz the effect depends on how many source files are unchanged between builds.ccache
cache size limit in 1GB. Thus it may cause cache uploading timeouts in perspective. I dunno how much data Travis' 3 min caching timeout translates into, so can't adjust limits myself upfront.-j<...>
tomake
args since all Travis builders are 2-core. This only affects the project itself (brew
uses its ownmake
args which already include-j<...>
, seebrew --env
output).