Generic formatted issue reports
On this page
If your third-party analyzer is not supported by SonarQube then you can import the reports by using the SonarQube generic issue format. No plugin is required.
The external issues will be taken into account by SonarQube in the analysis report, but the rules corresponding to these issues will not be visible on the Rules page nor reflected in quality profiles. This means that the rules that raise external issues must be managed in your third-party tool.
Setting up the import
- Set up the generation of the third-party reports in the generic issue format according to the specifications below.
- Set up the import of the report files by defining the analysis parameter
sonar.externalIssuesReportPaths
on the CI/CD host with the list of import directories or files. to define the list of report files to be imported during your project analysis. This parameter accepts a comma-delimited list of paths (A file path definition is either relative to thesonar.projectBaseDir
property, which is by default the directory from which the analysis was started, or absolute.).
Generic issue format specifications
The issues report must contain, an array of Rule objects (rules
) and an array of Issue objects. The figure below shows the different object types involved. The report fields for each object type are listed in the table below. For information about Clean Code attribute, software quality, impact, and severity, see Clean Code.
The generic issue format has changed with SonarQube 10.3. The previous format is deprecated. If you use it, SonarQube will apply the following default values:
- For the cleanCodeAttribute field: CONVENTIONAL
- For the softwareQuality field: MAINTAINABILITY
- For the severity field: MEDIUM
List of report fields
The table below lists the fields by object type of the generic issue report format.
Object | Field | Format | Description | Mandatory |
---|---|---|---|---|
Rule | id | string | Rule identifier. | x |
name | string | Rule name. | x | |
description | string | Rule description. | ||
cleanCodeAttribute | string | Clean code attribute associated with the rule (code characteristic checked by the rule). Possible values:
| x | |
impacts | Array of Impact objects | List of software qualities to which the rule’s Clean Code attribute contributes with a specific impact. | x | |
issues | Array of Issue objects | List of issues raised by the rule. | x | |
Issue | primaryLocation | Location object | Primary location of the issue in the code. | x |
effortMinutes | string | Evaluated issue solving time in minutes. Default value: 0 | ||
secondaryLocations | Array of Location objects | Secondary locations of the issue in case several places in the code are concerned. | ||
Impact | softwareQuality | string | Software quality. Possible values:
| x |
severity | string | Associated level of impact. This level corresponds to the severity level of an issue raised through the rule. Possible values:
| x | |
Location | message | string | Text message displayed at the location and describing the issue. | x |
filePath | string | Object used to locate the code to which the issue refers inside a file. | x | |
textRange | TextRange object | Object used to locate the code to which the issue refers inside a file. | For secondary locations only | |
TextRange | startLine | string | Start line of the code to which the issue refers. | x |
endLine | string | End line of the code to which the issue refers. | ||
startColumn | string | Start column of the code to which the issue refers. | ||
endColumn | string | End column of the code to which the issue refers. |
Report file example
Below is an example of the expected format.
Was this page helpful?