If SonarQube's results are not relevant, developers will push back on using it. That's why configuring the Exclusions / Inclusions for each project is a very important step. Doing so allows you to remove noise, like the issues and duplications marked on generated code or the issues from rules that are not relevant for certain types of object.
SonarQube gives you several options for configuring exactly what will be included / excluded. You can
- completely ignore some files or directories
- exclude files/directories from Issues detection (specific rules or all of them) but analyze all other aspects
- exclude files/directories from Duplications detection but analyze all other aspects
- exclude files/directories from Coverage calculations but analyze all other aspects
Defining Source Code Scope
We recommend that you exclude generated code, source code from libraries, etc. There are four different ways to narrow your analysis to the source code that will be relevant to the development team. You can combine them all together to tune your analysis scope.
sonar.sources property to limit the scope of the analysis to certain directories.
Some project modules should not be analyzed and consolidated with global project measures. For instance: sample modules, integration tests modules, etc. To exclude those modules, at project level, go to Configuration > Settings > Exclusions > Files and set the Module Exclusions property. The format is a comma-separated list of modules:
module1_to_exclude,module2_to_exclude. If a module's artifactId differs from its module name (the directory name), it is the artifactId that should be used instead of the module name
You can also work the other way around with inclusions by setting the Module Inclusions property. Be careful: the root project must be added to the list.
Most language plugins offer a way to restrict the scope to files matching a set of extensions. Go to Settings > General Settings > LanguagePlugin and set the File suffixes property:
It is possible to exclude specific files from being analyzed. At project level, go to Configuration > Settings > Exclusions > Files and set the:
sonar.exclusionsproperty to exclude source code files
sonar.tests.exclusionsproperty to exclude unit test files
Global exclusions that will apply to all projects can also be set. Go to Settings > General Settings > Exclusions > Files and set the
Since version 3.5, you can also work the other way around by setting inclusions. Go to Settings > General Settings > Exclusions > Files and set the
See the Patterns section for more details on the syntax.
Switching Off Issues
You can have SonarQube ignore issues in files or in sections of file by file content, by file path pattern, or both. See the Patterns section for more details on the syntax.
File Exclusion Patterns
Set the File Exclusion Patterns property to ignore all issues on files that contain a block of code matching a given regular expression.
Example: Switch off all issues on files containing
Block Exclusion Patterns
Set the Block Exclusion Patterns property to switch off all issues on specific blocks of code while continuing to scan and mark issues on the remainder of the file.
Note: If the first regular expression is found but not the second one, the end of the file is considered to be the end of the block.
Example: Switch off all issues included in
BEGIN-GENERATED / END-GENERATED blocks.
Multi-criteria Exclusion Patterns
Set the Multi-criteria Exclusion Patterns property to switch off all issues on specific components, coding rules and line ranges.
Examples: Switch off:
- all issues =>
- all issues on the Java file
- all issues in the Java package
- all issues of a specific rule =>
- all issues of a specific rule on a specific file =>
- all issues on specific lines: 10, 25 and 90 =>
- all issues on a line range =>
- all issues on several line ranges =>
<TODO> Update the screenshot
Multi-criteria Inclusion Patterns
It is the opposite of the Multi-criteria Exclusion Patterns property.
Examples: Raise issues against:
- files in the Java package
- the DesignForExtensionCheck rule on Java file
<TODO> Update the screenshot
Excluding from Duplications Detection
You can prevent some files from being checked against duplications.
To do so, go to Settings > General Settings > Exclusions > Duplications and set the Duplication Exclusions property. See the Patterns section for more details on the syntax.
Excluding from Code Coverage
You can prevent some files from being taken into account for code coverage by unit tests and integration tests.
To do so, go to Settings > General Settings > Exclusions > Code Coverage and set the Coverage Exclusions property. See the Patterns section for more details on the syntax.
Path can be defined either as relative or absolute.
The following wilcards can be used:
|*||zero or more characters|
|**||zero or more directories|
|?||one single character|
Relative paths are based on the fully qualified name of the component (that is displayed in the red frame below):
Note that for Java (only), replace "." package separator by "/" and add ".java" extension.
To define absolute path, start the pattern with "file:"