Extending the code analysis

• defining rules in extensions/rules folder in sonarqube server is no longer supported by this plugin

Extending rules in supported code analysers

If you're using a patched or not-yet-supported version of an integrated code checker (like Cppcheck), you probably want to see those new checks in SonarQube, too. To do this, you have to:

1. Define those rules using the XML format described further below in a file "rules.xml"
2. Paste the content of file into the relevant configuration property in the SonarQube server.
3. Restart the SonarQube server
4. Make sure the newly added rules are visible in the quality profile; enable them
5. Run the analysis

The format of the rules file

The format of rules file is expected to be the following:

<rules> 
  <rule key="RULE_ID">
    <name><![CDATA[ ... put here the human readable name of this rule ... ]]></name>
    <configKey><![CDATA[RULE_ID@$(EXTERNALSENSORCLASS)]]></configKey>
    <category name=" ... category type ... " />
    <description><![CDATA[ ... put here the human readable description of this rule ... ]]></description>
  </rule>
</rules>

Where the fields have the following semantics:

Tag/Attribute	MySql	Semantic
key [RULE_ID]	varchar(200)	Id of the rule, should match the ID in the external reports. Note: Only alphabetic characters, digits and underscores are permitted for declaring the key. First sign should not be a digit.
name	varchar(200)	Can be really anything, in the quality profile in SonarQube its the first name that is displayed per rule
configKey	varchar(500)	This key is used later by the sensor to configure the code analyzer ([Extending+Coding+Rules] (http://docs.codehaus.org/display/SONAR/Extending+Coding+Rules))
category name		Can be anything, examples include Maintainability Style Usability etc
description	mediumtext	In the quality profile in SonarQube UI, the description will be show after expanding each rule

Example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<rules>
  <rule key="Te0001DataContextCannotBeSet">
    <name><![CDATA[Te0001DataContextCannotBeSet]]></name>
    <configKey>
      <![CDATA[Te0001DataContextCannotBeSet@PC_LINT]]>
    </configKey>
    <category name="Maintainability" />
    <description>
      <![CDATA[ Data Context Should no be set, please use another approach ]]>
    </description>
  </rule>
</rules>

It is also possible to add hyperlinks to the description, use <a> tags.

<description>
  <![CDATA[<a href="http://example.com/xyz.html">Link</a>]]>
</description>

Usage of unsupported code checkers

If you're using a code checker which is not supported by the plugin, this feature is for you. It allows to feed violatios into SonarQube in a code checker agnostic way. To do this follow the steps below:

1. Create a XML file describing the rules and place it in global setting in the SonarQube server under sonar.cxx.customRules.cxxexternal Use the format described above. You can import multiple custom rules by clicking the Add value and save the settings

2. Run your checker and create a report

3. Transform the report such that it conform to the following RNG schema:

   <element name="results" xmlns="http://relaxng.org/ns/structure/1.0">
     <zeroOrMore>
       <element name="error">
         <attribute name="file"/>
         <attribute name="msg"/>
         <attribute name="id"/>
         <attribute name="line">
           <data type="integer" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" />
         </attribute>
         <text/>
       </element>
     </zeroOrMore>
   </element>

Where the fields have the following semantics:

Tag/Attribute	Semantic
file	Source file, relative to project path
line	Line number where the violation occurres
id	The ID of the violated SonarQube rule
msg	Description of the violation

4. Set the property **sonar.cxx.externalrules.reportPath** to point to the location of transformed report (relative to project root) and run one analysis.

Resources

Below you find a list of code analyzers which have already been integrated using this feature and according resources. The setups have been proven to work in one particular environment; you may need to adapt it to make work in yours.

Tool	Usage
cpplint	Create the rules profile using the profile creator script: python cpplint_createrules.py cpplint.py This will generate the following files: cpplint.xml: that should be copied to $SONARQUBEHOME/extensions/rules/cxxexternal cpplint_mod.py: that should be used to check the code After this you can run the cpplint_mod.py against any source file like this: python cpplint_mod.py source.cpp 2> report.txt The output file report.txt needs to be converted to the XML format described above. For convenience a Perl script is available here and can be run as follows: perl cpplintReport2checkstyleReport.perl report.txt splint-result-0.xml
Intel Inspector XE 2013	Copy the Intel Inspector rules to $SONARQUBEHOME/extension/rules/cxxexternal and restart the server Modify the used SonarQube quality profile to accommodate the newly added rules Run your test/application using the Intel Inspector and generate a CSV report Convert the report with: python intelInspectorReport_2_cppcheckReport.py in.csv out.xml The out.xml can be then used during the analysis to feed the Intel Inspector results into SonarQube.