If SonarQube's results aren't relevant, developers will push back on using it. That's why precisely configuring what to analyze 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 aren't relevant for certain types of objects.

SonarQube gives you several options for configuring exactly what will be analyzed. You can

Ignore Files

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.

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 the 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), use the artifactId instead of the module name

You can also work the other way around with inclusions by setting the Module Inclusions property to a list of only those modules you want analyzed. Be careful: the root project must be added to the list.

File Suffixes

Most language plugins offer a way to restrict the scope of analysis 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 specific files from analysis. At the project level, go to Configuration > Settings > Exclusions > Files and set the:

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.test.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 to the list of files that should be analyzed. If you set an inclusion, then only the files or modules listed there will be included in the analysis.

See the Patterns section for more details on the syntax.

Ignore Issues

You can have SonarQube ignore issues on certain components and against certain coding rules. Go to Configuration > Settings > Exclusions > Issues.

Note that the properties below can only be set through the web interface because they are multi-valued.

Ignore Issues on Files

You can ignore all issues on files that contain a block of code matching a given regular expression.

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

Ignore Issues in Blocks

You can ignore 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: Ignore all issues included between GEN-FIRST and GEN-LAST and between BEGIN-GENERATED and END-GENERATED blocks.

Ignore Issues on Multiple Criteria

You can ignore issues on certain components and for certain coding rules.

Examples:

Restrict Scope of Coding Rules

You can restrict the application of a rule to only certain components, ignoring all others.

Examples:


Ignore Duplications

You can prevent some files from being checked for 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.

Ignore Code Coverage

You can prevent some files from being taken into account for code coverage by unit 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.

Patterns

Paths are relative to the project base directory.

The following wildcards can be used in either kind of path:

WildcardMatches
*zero or more characters
**zero or more directories
?a single character

Relative paths are based on the fully qualified name of the component (like the ones displayed in the red frames below):

Note that for Java (only), the fully qualified name is not exactly the one that is displayed. You have to replace the "." package separator with "/" and add the ".java" extension. For the above example, the fully qualified name is "org/sonar/api/utils/KeyValueFormat.java". For other languages, the path is displayed in the fully qualified format automatically.
 

# Exclude all classes ending by "Bean"
# Matches org.sonar.api.MyBean.java, org.sonar.util.MyOtherBean.java, org.sonar.util.MyDTO.java, etc.
sonar.exclusions=**/*Bean.java,**/*DTO.java

# Exclude all classes in the "org.sonar" package
# Matches org.sonar.MyClass.java, org.sonar.MyOtherClass.java
# But does not match org.sonar.util.MyClassUtil.java
sonar.exclusions=org/sonar/*

# Exclude all COBOL programs in the "bank" directory and its sub-directories
# Matches bank/ZTR00021.cbl, bank/data/CBR00354.cbl, bank/data/REM012345.cob
sonar.exclusions=bank/**/*
# Exclude all COBOL programs in the "bank" directory and its sub-directories whose extension is .cbl
# Matches bank/ZTR00021.cbl, bank/data/CBR00354.cbl
sonar.exclusions=bank/**/*.cbl