Travis: Use workspaces and per job persisttent ccache #2399
Conversation
|
Forgot to mention that I indend to add a mechanism that wipes the ccache at the start if a magic string appears in the commit message like '[travis wipe ccache]' so we can easily test it will still not time out with an empty cache. |
Codecov Report
@@ Coverage Diff @@
## master #2399 +/- ##
==========================================
+ Coverage 89.15% 89.31% +0.15%
==========================================
Files 170 168 -2
Lines 52853 52946 +93
==========================================
+ Hits 47121 47288 +167
+ Misses 5732 5658 -74
|
|
This is all great stuff, thanks for looking into this, keeping the tests nice is often under appreciated. Feel free to merge when happy. BTW you probably know this but we are limited to 5 test slots, so if you do make changes to non-cron be sure to keep the number of jobs needed always <= 5. |
We proceed in 2 stages (as before, but using workspaces for persistence): 1. In the 'build' stage, we clone the repo, build it and save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace 2. In the 'test' stage, rather than cloning the repo, multiple jobs pull down the same workspace we built to run the tests from This enables: - Reuse of the build in multiple test jobs (this is what we used the Travis cache for before) - Each job having a separate persistent Travis cache, which now only contains the ccache. This means all jobs, including 'build' and 'test' jobs can make maximum use of ccache across runs. This drastically cuts down build times when the ccache hits, which is very often the case for 'test' jobs. Also, the separate caches only store the objects build by the particular job that owns the cache, so we can keep the per job ccache small. If the commit message contains '[travis ccache clear]', the ccache will be cleared at the beginning of the build. This can be used to test build complete within the 50 minute timeout imposed by Travis, even without a persistent ccache.
Actually, as stages run in sequence anyway, you can have 5 jobs per stage to roughly the same effect. With that in mind I am changin non-cron to build both wiht GCC and Clang, and to run the MT tests with Clang, and the rest with GCC. Hopefully that will pick up all the things that only showed up in cron before due to clang not being run, while taking the same time as before in the worst case. |
|
Doing a dual-build seems a good approach. BTW if there's a way now to avoid using all 5 slots that would be nice as if allows some other regression(e.g. for a branch/pull) to start. |
|
Could merge --dist with --vlt and then run those split over 2, that would put 4 jobs in the test stage taking roughly the same time. I'm not sure we can do much better (could do 3 jobs, with just --dist --vlt --vltmt alll together and split 3 ways, running 1 shard with clang, but that does feel a bit murky). |
|
I will watch out and clean up cron failures, hopefully there will not be many. |
3 participants
This changes the Travis build to use workspaces:
This enables:
Workspaces rely on the travis cacher, so this does not quite fit with #2393 due to travis-ci/casher#54, but I have a plan on how to make it fit (essentially have a 'freebsd' stage that runs both build and test in the same job until the casher issue is fixed).
Note: I change all jobs to non-cron for testing. Will set back to cron before merging.
I will now run this twice in this PR to check the cache effect, on the non-cron jobs it should be about 3x when the persistent ccache hits.