-
Notifications
You must be signed in to change notification settings - Fork 362
sonar.cxx.other.reportPaths
The cxx plugin provides an open interface to integrate any external tool into SonarQube. In principle, the sensor works similar to the Generic Issue Import Format, but bypasses its limitations:
- You can manage the rules within SonarQube; for instance, you can mark them False Positive.
- You can manage the activation of the rules that raise these issues within SonarQube. Rules are visible on the Rules page or reflected in Quality Profiles.
The implementation always works in three steps:
- Definition of rules and register them with the SonarQube Server via an XML file (see sonar.cxx.other.rules).
- Activate the rules in a Quality Profile.
- Create XML reports with the external tool and transfer them to SonarQube via the SonarScanner.
Note: The cxx plugin itself does not run the tool, you have to do that yourself beforehand. The sensor only reads the report generated by the tool!
Run the external tool and create a report with the issues. Transform the report to match the following RNG schema.
Hint: The cxx plugin has a built-in XLS transformation. This is especially handy when XML data needs to be converted before being read in with the cxx plugin. See sonar.cxx.xslt for more information.
<element name="results" xmlns="http://relaxng.org/ns/structure/1.0">
<zeroOrMore>
<element name="error">
<attribute name="id"/>
<attribute name="file"/>
<attribute name="line">
<data type="integer" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" />
</attribute>
<attribute name="column">
<data type="integer" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes" />
</attribute>
<attribute name="msg"/>
<text/>
</element>
</zeroOrMore>
</element>
Where the fields have the following semantics:
tag | semantic |
---|---|
id | The ID of the issue. This must match with the rule key und must be unique. |
file | source file with absolute path or relative path (relative to project base directory) |
line | line number where the issue occurres (optional) |
column | column number where the issue occurres (optional) |
msg | description of the issue (optonal) |
If the tool and transformation was executed successfully, a report like the example below should be generated:
<report>
<error file="C:\MyProject\sample.cpp" line="42" id="TOOL.0815" msg="This declaration is of the non standard type unsigned long long."/>
<error file="C:\MyProject\sample.cpp" line="67" id="TOOL.0819" msg="This string literal might be more readable if expressed as a raw string literal."/>
</report>
- Definition of rules and register them with the SonarQube Server via an XML file (see sonar.cxx.other.rules).
- Then check if the file extensions read in by the cxx plugin are set (sonar.cxx.file.suffixes).
- The rules for which you want to generate issue must be activated in the Quality Profile of your project. You can find instructions on how to do this under Manage Quality Profiles.
- Set the analysis parameter
sonar.cxx.other.reportPaths
in the configuration filesonar-project.properties
of your project. The Report Paths link describes the configuration options. - Execute the SonarScanner to transfer the project with the report to the SonarQube Server.
Sample for sonar-project.properties:
sonar.cxx.other.reportPaths=sample*.xml
- If no results are displayed after a successful scan, check if rules are available in the Quality Profile (see sonar.cxx.other.rules).
- If no results are displayed after a successful scan, check Manage Quality Profiles first.
- If scanning is failing, check items listed under Troubleshooting Configuration.
- If no issues are displayed for your source code in SonarQube, check the items listed under Troubleshooting Reports.
- In the case of incomplete scans, Detect and fix parsing errors gives advice on how to fix this.