On Wed, Oct 06, 2021 at 10:38:18PM -0400, Jeff King wrote: > The reason for that is that I didn't find it by inspection; I've started > running my personal builds through coverity. It wasn't too bad to set up > with a GitHub Action, like so: > > [...] It looks like this would never cause the build to fail, but is merely responsible for sending any warnings off to Coverity's UI? > Is there interest in having something like this in the main repo? We'd > need to tweak some values: > > - we have to send the project name (here peff/git); we can presumably > get this on the fly from the Actions environment Yes; searching through [1] it looks like that is called $GITHUB_REPOSITORY. [1]: https://docs.github.com/en/actions/learn-github-actions/environment-variables > - any repo which wants to use this has to set up the secret token > (COVERITY_SCAN_TOKEN here). That involves creating a coverity > account, and then setting the token in the GitHub web interface. > Presumably we'd just bail immediately if that token isn't set, so > forks aside from git/git would have to enable it independently. > > - likewise it needs the email address for the coverity account. That > could probably be set in the environment, too. These both seem reasonable to me, too. > There are tons of existing warnings, many of which are false positives. > But it keeps track of which problems are new, and emails out a summary > of only the new ones (which is how I saw the leak here, which just hit > next). I don't care all that much about leaks here (we have other > techniques for finding them), but when Stefan used to do regular > coverity builds in the past, it routinely found useful errors. I'm generally pessimistic about tools like Coverity, but I share your experience that Coverity warnings are actually pretty high quality. Or at least they have a high enough signal-to-noise ratio that it makes them worth looking through. So I would be happy to have forks of GitHub have fewer barriers to use this tool. Thanks, Taylor
