Use Travis workspaces #228
Conversation
|
It shaves about 11 hours off of full build time (~5,5 hours of real time since 2 OSX jobs run in parallel). |
|
On a closer inspection, it definitely shaves off machine time massively, but doesn't save real time much because the Linux jobs are now the critical path, and full-building the 20 OSX jobs takes about the same time as the 48 Linux ones. Moving them to the Final stage would fix this, but running Linux builds will be delayed by ~40 min (~10 min for rebuilds) that the S1 stage takes -- and they will not run at all if it fails. Is this acceptable? If you need to debug some issues with a specific job, you can disable everything else temporarily anyway (and then edit the history to remove those temporary commits). |
|
I think it's ok. In any case it's usually best to disable all but one or two jobs if there are issues. Also the Linux side is far more easier to debug than macOS because it can be done locally via Docker. |
With only 1 OSX job in S1, the Linux part is now the critical path and holds the build time back
|
Let's give this a try. |
* Use one job for MacOS Homebrew builds cache with Travis workspaces * Brew build job needs to both feed to other jobs and cache between builds * Move Linux jobs to the Final stage With only 1 OSX job in S1, the Linux part is now the critical path and holds the build time back
A new Travis CI feature, workspaces, allows to use one MacOS cache job to build FFMpeg instead of 20.
It's currently in beta -- so it's your call whether it's good enough for production use. It worked for me well save for a small nitpick when I used this project to try it out.