Bamboo PMD/Checkstyle integration

[John Chaney]

I'm trying to get Bamboo running pmd, checkstyle and other static analysis tools. The plugins listed in the market place are really out of date, and when I looked into the Sonar Tasks plugin it seems just a bit behind the version (4.3 and I'm running 4.4.4). I'd really like to get these incorporated into our CI process but there seems to be a gap in what is currently provided. Does anyone have any insight on how this could be done using whats available today?

Thanks.

[John Chaney · Accepted solution]

Since the Sonar Tasks plugin was managed by a third party, I had to wait until the release for that software supported my current version. As they were undergoing a major overhaul to support Bamboo 5.0 at the time, it took a bit longer than I would have liked. The support for the typical parsers seems a bit lacking, but as long as there are outside parties providing the functionality I need things should be fine.

I would also like to add that the Sonar plug for Bamboo has been working really well and seems to meet all of our needs for state code analysis.

[Markus Schulte]

I am providing two addons, View Checkstyle/CodeSniffer supports Checkstyle, PHP_CodeSniffer, and others, View PMD-pmd/PHPMD (mess detector) supports PMD and PHPMD. CPD will come soon, have a look at my Marketplace vendor page.

[Chris Lemmons]

I'm going to give an answer, although it isn't a very good one, it is the best I've been able to find. I'm also not familiar with the precise tools you are using, though I suspect this approach will work, given enough massaging.

We use cppcheck for our static analysis. The cppcheck executable (and dll) are checked into the source repository (you can use a separate /tools folder to keep things discrete).

We have a ruby (substitute a scripting language of your choice) script that handles actually running cppcheck with the appropriate arguments. (It also includes some clever logic to run things in parallel, although that's not necessary.)

In rubyesque pseudocode, the master script looks like this:

all_files = get_all_files() # Reads the build scripts to find all the files that are relevant to the project.
all_files.each {|file|
    output_base = static_analysis_ouput/"+strip_filename(file)
    run_cppcheck(file, output_base + ".txt")
    convert_to_junit_xml(output_base + ".txt", output_base + ".xml")
}

Of course, the get_all_files() function will depend on your project and may or may not be as simple as ours. Our projects build with msbuild, so we just use an xml parser to read them and get the source filenames.

Since it looks like you use Java, you may be able to skip the convert_to_junit_xml() call, if your tools output JUnit tests directly. What I do is have it convert each file to a single unit test. If the txt file has no static analysis warnings, then I issue a successful unit test. Otherwise, I include the text of the failures as the output of the test and mark the test as failed.

So each xml file looks like one of these:

Success

<testsuites tests='1' failures='0' disabled='0' errors='0' time='0' name='FailedCppChecks'>
 <testsuite name='FailedCppCheck' tests='1' failures='0' disabled='0' errors='0' time='0'>
  <testcase name='derived.from.file' status='run' time='0' classname='CppCheck'/>
 </testsuite>
</testsuites>

Failure

<testsuites tests='1' failures='1' disabled='0' errors='0' time='0' name='FailedCppChecks'>
 <testsuite name='FailedCppCheck' tests='1' failures='1' disabled='0' errors='0' time='0'>
  <testcase name='derived.from.file' status='run' time='0' classname='CppCheck'>
   <failure message='{number of static analysis warnings} failures' type=''>{text of static analysis warnings}</failure>
  </testcase>
 </testsuite>
</testsuites

By converting each file to a single unit test (with a name derived from the file), I get a predictable set of "unit tests". If I decide that a particular file isn't worth fixing yet, I can quarantine it. (Not a great solution, since the introduction of new warnings in that file will go unnoticed.) Also, if you have too many unit tests, Bamboo gets more than a little slow accessing those pages.

I truly hope this isn't the best answer you get, because it isn't very good and requires a fair bit of work on your part to implement and maintain. But it works for me and it is better than no answer at all.