CI Improvements #3975
CI Improvements #3975
Conversation
We used to only execute Coverity analysis on the 'development' branch before commit 998f001 (Refine build limitation, 2014-01-15), which refined Coverity build limitations. While we do not really use the 'development' branch anymore, it does still make sense to only analyze a single branch, as otherwise Coverity might get confused. Re-establish the restriction such that we only analyze libgit2's 'master' branch. Also fix the message announcing why we do not actually analyze a certain build.
|
The main reason for allowing valgrind runs to fail is so that travis can report back with success before they're done, as they take considerably more to run than the others. |
|
Does this really make sense though? I mean when you take this particular build, the macOS builds are still two minutes slower compared to the valgrind builds (11 minutes for valgrind, 13 minutes for macOS). So there's not much to be gained by this, actually. |
When running a Coverity build, we have to provide an authentication token in order to proof that we are actually allowed to run analysis in the name of a certain project. As this token should be secret, it is only set on the main repository, so when we were requested to run the Coverity script on another repository we do error out. But in fact we do also error out if the Coverity analysis should _not_ be run if there is no authentication token provided. Fix the issue by only checking for the authentication token after determining if analysis is indeed requested.
Our valgrind jobs haven't been failing for several builds by now. This indicates that our tests are sufficiently stable when running under valgrind. As such, any failures reported by valgrind become interesting to us and shouldn't be ignored when causing a build to fail. Remove the valgrind job from the list of allowed failures.
a4b1082 to
0334bf4
Compare
|
Just realized that we're also producing an errored job because of a missing Coverity authentication token if Coverity is actually not going to run. Added another commit fixing this issue. |
|
The Mac build wasn't always this slow. But I noticed on a different project that Travis won't send the "green" message until the whole build is complete anyway, so it's probably fine. We're not doing a lot in the valgrind build anyway, since we've no code to fail in case valgrind detects new leaks. |
Just realized our Coverity builds were not running for nearly three months. Seems as if Coverity did change the download URLs for their build tools. I've fixed these and re-added a check so that we only let Coverity analyze our master branch.
I also removed valgrind from the allowed failures. I didn't spot any failures from valgrinds in the last builds, so I'd argue its a good thing to do to notice new failures. I'd also like to disallow failures for Coverity, but unfortunately the build is still too unstable due to quotas and occasional problems with downloading their toolset.