Skip to content

Extending the code analysis

Jorge Costa edited this page May 7, 2014 · 36 revisions

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. Ui Settings
  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 Semantic
key [RULE_ID] Id of the rule, should match the ID in the external reports
name Can be really anything, in the quality profile in SonarQube its the first name that is displayed per rule
configKey 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 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>

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 Ui Settings 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
  1. 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

  2. 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
  1. Copy the Intel Inspector rules to $SONARQUBEHOME/extension/rules/cxxexternal and restart the server
  2. Modify the used SonarQube quality profile to accommodate the newly added rules
  3. Run your test/application using the Intel Inspector and generate a CSV report
  4. 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.
Clone this wiki locally