Making Your Open Source Code Shine With Travis CI and Coverity Scan Service

This year at LinuxCon EU, I gave a talk titled Static Analysis of Your OSS Project with Coverity. In this talk, I briefly touched on using the Travis Continuous Integration system to submit builds to the Coverity Scan service (slide 22). This is an extremely easy way for GitHub projects to use static analysis, and I think it deserves some more detail. While I was setting it up for another project I’m working on, I collected some notes to provide a steb-by-step guide to enable it for a project you have on GitHub.

The project I’ll be using as an example is wpan-tools, the user space tools for Linux IEEE 802.15.4 stack. It is written in C with autotools for the build system, and it has only a few dependencies, making it easy to understand this guide. The final goal is to automatically submit new builds to the Coverity Scan Service whenever new code is pushed to a specific branch. On the way, we will enable builds with GCC and Clang for every push to the GitHub repository by using Travis CI.

As a pre-requirement for this is that that your project must be hosted on GitHub (requirement of Travis CI), and it must be open source software (requirement of Travis CI and Coverity Scan Service). Both solutions are also available for proprietary code as a paid service, but this will not be covered in this article.

Step 1: Set up Your Build with Travis CI

Once logged in, you should be able to sync your repositories from GitHub.

Enable the repository you want to work on.

Create a .travis.yml file for your own needs

In the case of my example, I want to build for both available compilers: gcc and clang. I have a project written in C and two dependencies that need to be installed: libnl-3-dev and libnl-genl-3-dev. For the build itself, I need to run autogen.sh first to get the configure script because I am building from git. With this information, I can create a simple .travis.yml that caters to my needs:

If you want to use the new container based infrastructure you need add sudo: false and change the dependency handling accordingly. This new setup seems to be faster and the old one is already considered legacy, so I would recommend to upgrade:

A word of warning about the file format. Make sure you use the correct indent. It is just as picky as python about it. :-)

If you have a more complicated build setup you should have a look at the Travis CI documentation which covers way more then the small preview I gave here.

After adding the .travis.yml file with this content to your repo, push it to GitHub and your first build should run. For wpan-tools the current status is:

Step 2: Use Travis CI to Submit Builds to Coverity

Log in with your GitHub account. If you already have another Coverity Scan account with the same email address you use for your GitHub account, it will be detected and the GitHub account will be linked to your existing account.

Add a new project using the GitHub project type. An index with all of your GitHub projects could be found here when logged in.

Configure Travis-CI to submit builds to Coverity Scan Service

Coverity already provides most of the details needed to fill into your .travis.yml file on the project pages if you go to Submit Build -> Configure Travis CI. My example looks like this (the secure token was replaced with XXX here and would look way longer in your case):

Another word of warning here: make sure you add the covery_scan addon section to the already existing addon section for apt. If you just add another addon section below, it will override the first one and no package dependencies will get installed.

The only other change we did compared to the generated config is adding the needed autogen.sh into the build_command_prepend. Some more information can be found on the Coverity Scan documentaion about the Travis CI integration.

If you now push your code to the coverity_scan branch it will trigger a build and submit the result for a scan. The current status for wpan-tools is:

Squashing Open Source Bugs

As you can see on the screen shot below our first run revealed 4 defects in 16800 lines of code (after the C preprocessor). With a defect density of 0.24 this is way below industry average which is set to one per 1000 lines of code here. In other words this means we only have 2.4 defects per 10000 lines of code. Even these four are fixed now and we will try to keep a zero defect rate for the future now that we enabled this functionality on our main repository. I hope you enjoyed this short post and are able to enable static analysis for your project as well.

Share this:

Author: Stefan Schmidt

Stefan Schmidt has been a FOSS contributor for over 10 years and currently works on Enlightenment Foundations Libraries, Wayland and the IEEE 802.15.4 and 6LoWPAN Linux stack.
View all posts by Stefan Schmidt