-
Notifications
You must be signed in to change notification settings - Fork 4
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
Cached build of repos when doing TravisCI build #223
Conversation
WIP WIP
Codecov Report
@@ Coverage Diff @@
## develop #223 +/- ##
=========================================
Coverage ? 91.8%
=========================================
Files ? 84
Lines ? 3671
Branches ? 0
=========================================
Hits ? 3370
Misses ? 301
Partials ? 0
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
b5ae48b
to
2c1c505
Compare
2c1c505
to
5d48c9a
Compare
b07385e
to
8fabc1f
Compare
8fabc1f
to
fbd3e44
Compare
Pay no attention to this for now, testing ideas for doing caching on TravisCI
but if you must know...
Previously, running the tests in debug and with code coverage was timing out because it took so long (well over an hour). Now a TravisCI test take ~7 minutes if the cache is already populated, ~25 minutes otherwise for a full rebuild. 🎉
Instead of running the tests on TravisCI by compiling everything that would normally be in the bundle, each upstream repository is built separately, and then installed to a cached location doing
make install
. (This required changes to quite a few repos to make sure the install works correctly). On subsequent builds this cached install directory is used instead of rebuilding. The repos are rebuilt if the scripts detect any of several changes (different repo branch name, different git hash tag, an upstream repo was rebuilt, change in order of repo dependencies.... ). The soca repo is always rebuilt every time.The
ccache
utility is used to greatly accelerate compiling the C files even when an entire repo needs to be rebuilt. This of course only accelerates the C files, not Fortran, but it's still useful.By doing the compilation separately this way, the build type can be changed for each repo. Now, the upstream repos are all built with
RelWithDebInfo
to help run the tests faster, and soca is built withDebug
to catch more errors. Code coverage instrumentation usually slows down the code, but now it can be enabled for soca only, and not all the upstream repos. We can choose to instead build all repos, or a subset of the repos, in debug for a longer nightly/weekly cron run.Requires: