12 Replies Latest reply: May 16, 2012 1:35 AM by nikantonelli RSS

My developers are performing Coverity analysis on their local source files.  How should I set up my Streams and Projects?

Coverity Ninja
Currently Being Moderated

Originally published on 2011-10-07 18:04


It's often the case that you want to have your developers perform a Coverity analysis before they check their code in to the main source branch. Here's how to set up your Streams and Projects in CIM in order to keep the developer's working code from interfering with your overall CIM results and trending.


This example assumes that you have four developers: Bob, Carol, Ted and Alice; all working on a project named "Alpha". Each developer has their own sandbox where they can check out code from the main branch, do their own development work, perform a Coverity analysis, and then check in their changed code to their Source Control system. This example also assumes that you've got a main Coverity build and analysis that you run once per day, which happens outside of the sandbox of any of the developers.


1) Set up the following Streams:

  • Alpha_Main
  • Alpha_Bob
  • Alpha_Carol
  • Alpha_Ted
  • Alpha_Alice


2) It may be that you have been running the centralized build and analysis for some time, so that you already have Snapshots and Triage information present in 'Alpha_Main' (or its equivalent).  If this is the case, make sure you create the developer-specific Streams ("Alpha_Bob", "Alpha_Carol", "Alpha_Ted", and "Alpha_Alice") by *copying* the "Alpha_Main" Stream.  This will make sure that these Streams contain copies of the existing Triage information, so that defects that have been previously found and triaged (as "Intentional" or "False Positive") are triaged the same way in the developers' private streams.


3) Set up the following Projects, each containing the following Streams:

  • Alpha_Main (containing just "Alpha_Main")
  • Alpha_Bob (containing both "Alpha_Main" and "Alpha_Bob")
  • Alpha_Carol (containing both "Alpha_Main" and "Alpha_Carol")
  • Alpha_Ted (containing both "Alpha_Main" and "Alpha_Ted")
  • Alpha_Alice (containing both "Alpha_Main" and "Alpha_Alice")

4) Set up a policy about commits, such that:

  • Bob only commits to the Stream "Alpha_Bob"
  • Carol only commits to the Stream "Alpha_Carol"
  • Ted only commits to the Stream "Alpha_Ted"
  • Alice only commits to the Stream "Alpha_Alice"
  • The only person who commits to the stream "Alpha_Main"     is the automated daily Coverity build.

Note that as of CIM 5.4, there is no mechanism to enforce this policy. The best way to do this is to have the commit process wrapped in a script which sends the results to the correct stream based on the username of the developer running this script.

5) With this setup, you get the following benefits:

  • The metrics from the Project "Alpha_Main" are always accurate, and     reflect the status of the checked-in code
  • Developers building and analyzing subsets of the entire project does not     affect the metrics in the "Alpha_Main" Project or the "Alpha_Main"   Stream.
  • Each developer can use CIM to view just the defects that they introduced     in their local copy of the code by in the code they're working on by going     to CIM, looking in their project, and using the "Detected In" filter at the     bottom-left of the CIM screen. To display only the defects they introduced,     they would use this filter to Include their personal stream and Exclude the     main stream.
  • If a developer finds a defect in their private code and they triage it as     a "False Positive" or "Intentional", then that triage will also be applied,     as "Advance Triage", to the 'Alpha_Main' Stream. When they check in their     code and the Coverity analysis results are committed to the 'Alpha_Main'     stream, that triage will be automatically applied to the defect.