{{ message }}
CI Improvements#3975
Merged
Merged
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.
Member
Member
Author
|
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.
pks-t
force-pushed
the
pks/ci-improvements
branch
from
a4b1082 to
0334bf4
Compare
Member
Author
|
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. |
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.