Make ccache bigger for coverage builds. - #1567
Conversation
Sorry, something went wrong.
Codecov Report
@@ Coverage Diff @@
## master #1567 +/- ##
=======================================
Coverage 93.99% 93.99%
=======================================
Files 278 278
Lines 15398 15398
=======================================
Hits 14473 14473
Misses 925 925Continue to review full report at Codecov.
|
Sorry, something went wrong.
dopiera
left a comment
There was a problem hiding this comment.
Two nits, but more importantly, why does it work at all?
ccache documentation says: "Normally, there is no need to initiate cleanup manually as ccache keeps the cache below the specified limits at runtime and keeps statistics up to date on each compilation". Shouldn't we append this flag to cached_cxx instead?
Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @coryan, @houglum, and @dopiera)
ci/travis/build-docker.sh, line 211 at r1 (raw file):
echo echo "${COLOR_YELLOW}Print and clearing ccache stats: $(date)${COLOR_RESET}" ${ccache_command} --show-stats
Not a regression, but shouldn't ${ccache_command} be quoted?
ci/travis/build-docker.sh, line 212 at r1 (raw file):
1GiB
The documentation doesn't list GiB as a valid suffix (https://ccache.samba.org/manual/latest.html#_options). I think we should stick to Gi.
Sorry, something went wrong.
We need a bigger cache for the code coverage build. While most builds take 500MiB, the code coverage build takes nearly 1.5GiB. This will slow down all the builds by a few seconds, but speed up the coverage build (the longest pole in the builds right now) by minutes.
houglum
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
coryan
left a comment
There was a problem hiding this comment.
This was sitting in a draft, sorry:
ccache documentation says: "Normally, there is no need to initiate cleanup manually as ccache keeps the cache below the specified limits at runtime and keeps statistics up to date on each compilation". Shouldn't we append this flag to cached_cxx instead?
We could do that. That would not accomplish (a) print out the stats, which help me diagnose problems with the cache, and (b) we need to zero out the stats to avoid dirtying the cache on trivial builds. Admittedly I do not recall how important the latter thing is.
Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @dopiera)
ci/travis/build-docker.sh, line 211 at r1 (raw file):
Previously, dopiera (Marek Dopiera) wrote…Not a regression, but shouldn't ${ccache_command} be quoted?
Done.
ci/travis/build-docker.sh, line 212 at r1 (raw file):
Previously, dopiera (Marek Dopiera) wrote…1GiBThe documentation doesn't list GiB as a valid suffix (https://ccache.samba.org/manual/latest.html#_options). I think we should stick to Gi.
Done.
Sorry, something went wrong.
dopiera
left a comment
There was a problem hiding this comment.
Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dopiera)
Sorry, something went wrong.
dopiera
left a comment
There was a problem hiding this comment.
Sorry, my bad, I assumed that the default is lower than 2.5G
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dopiera)
Sorry, something went wrong.
We need a bigger cache for the code coverage build. While most builds
take 500MiB, the code coverage build takes nearly 1.5GiB. This will slow
down all the builds by a few seconds, but speed up the coverage build
(the longest pole in the builds right now) from about 37 to about 30
minutes.
This change is