[boost] Maintainers: Adding Coverity Scan to your library

Subject: [boost] Maintainers: Adding Coverity Scan to your library
From: James E. King, III (jking_at_[hidden])
Date: 2017-10-12 13:02:08

I have completed the work necessary to add Coverity Scan to Boost.Uuid and
wanted to share the steps involved.  This work can be carried into other
libraries fairly easily.

1. Go to Coverity Scan: https://scan.coverity.com/
2. Sign up/in with your Github account.
3. Create a project for your boostorg/library.  It will take about 24 hours
for them to activate your account so that you can use the results browser.

To run a coverity scan manually:

1. Check out your project master (or whatever branch you want to scan).
2. cd into BOOST_ROOT (where "libs/" is located)
3. Run the libs/uuid/covscan.sh script with the following environment
variables set:
    A. COVERITY_SCAN_TOKEN: the project token in coverity scan
    B. COVERITY_SCAN_NOTIFICATION_EMAIL: your email
    C. SELF: your library name, for example SELF=uuid for Boost.Uuid
4. You will need to clean up some cruft it leaves behind as the script is
designed for Travis CI - just a couple directories starting with "cov" and
a tar.xz file.

To integrate coverity scans for every pull request or push into master with
Travis CI:

1. Make sure you have Travis CI set up properly to build your project.
2. Copy the Coverity Scan stanza from libs/uuid/.travis.yml into your
.travis.yml file.  Note that the Boost.Uuid travis configuration now uses
jobs instead of matrix, as jobs allow for conditions.  I would encourage
you to convert your .travis.yml to use jobs as well.
3. The next pull request into master, or the next push into master, will
trigger a build, and any build for master will run covscan.sh and upload
the data.

You can add component regular expressions to ignore/omit other boost
library errors if you wish.  Here are the results for Boost.Uuid.  I have
not excluded other components yet:

https://scan.coverity.com/projects/boostorg-uuid

Initially I saw a flurry of "unhandled exception" items which I dismissed
as intentional (i.e. I want the test to segfault if an unexpected exception
is thrown so that I can debug it), and that will likely be a common
practice for test files, but should not be for implementations.  I also
caution folks against marking something as a false positive.  Approach it
with the mindset of, "it must be a fault of the library" before jumping to,
"it must be a fault in Coverity" and really convince yourself it is not a
code issue.

Even if you do not have travis integration in your library, running a
manual scan will help you improve the quality of your library, so I
recommend everyone at least do that much.

- Jim