Full documentation for SonarQube has moved to a new location: http://docs.sonarqube.org/display/SONAR

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Table of Contents

If SonarQube provides developers with information that are not relevant, they will likely push back the tool. That's why configuring Exclusions / Inclusions for each project to remove noise (such as generated code or issues that are not relevant for certain rules on certain types of object) is a very important step.

Defining Source Code Scope

Make sure to exclude genearated code, source code from libraries, etc. Four different ways are at your disposal to select source code that will be relevant to the development team. You can combine them all together to tune your analysis scope.

Source Directories

Set the sonar.sources property to limit the scope of the analysis to certain directories.

Skipping Modules

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. 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 use instead of the module name

You can also work the other way around with inclusions. Set the Module Inclusions property. Be careful: the root project must be added to the list.

File Suffixes

Each language plugin offers 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:

Excluding Files

It is possible to exclude some specific files from being analyzed. At project level, go to Configuration > Settings > Exclusions > Files and set the:

  • sonar.exclusions property to exclude source code files
  • sonar.tests.exclusions property 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 sonar.global.exclusions and sonar.global.tests.exclusions properties.

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 sonar.inclusions and sonar.test.inclusions properties.

Switching Off Issues

You have different ways to prevent certain types of issue to be logged on certain files.

File Exclusion Patterns

Set the File Exclusion Patterns property to switch off all issues on files that contain a block of code matching a given regular expression.

Example: Switch off all issues on files containing @javax.annotation.Generated:

Block Exclusion Patterns

Set the Block Exclusion Patterns property to switch off all issues on specific blocks of code.

Note: If the first regular expression is found but not the second one, the end of the file is considered as the end of the block.

Example: Switch off all issues included in GEN-FIRST / GEN-LAST or 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 com.foo.Bar => com/foo/Bar;*;*
  • all issues in the Java package com.foo => com/foo.*;*;*
  • all issues of a specific rule => *;checkstyle:com.puppycrawl.tools.checkstyle.checks.design.DesignForExtensionCheck;*
  • all issues of a specific rule on a specific file => com/foo/Bar;checkstyle:com.puppycrawl.tools.checkstyle.checks.design.DesignForExtensionCheck;*
  • all issues on specific lines: 10, 25 and 90 => com/foo/Bar;*;[10,25,90]
  • all issues on a line range => com/foo/Bar;*;[10-90]
  • all issues on several line ranges => com/foo/Bar;*;[10-90,92,98,120-150]

    <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 com.foo only => com/foo/Bar;*;*
  • the DesignForExtensionCheck rule on Java file com.foo.Bar only => com/foo/Bar;checkstyle:com.puppycrawl.tools.checkstyle.checks.design.DesignForExtensionCheck;*

<TODO> Update the screenshot

Excluding from Duplications

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.

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.


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 Path

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.


Absolute Path

To define absolute path, start the pattern with "file:"

  • No labels