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 11 Next »

Table of Contents


If SonarQube provides developers information with too much noise (Issues on generated code => Indeed, it is useless to analyze such code as you don't have any way to fix issues that would be raised, Issues that are not relevant in the context => For example, you may want to allow the usage of hard coded values for some objects, but you still want to forbid this usage everywhere else, etc.), they'll likely push back the tool. That's why configuring Exclusions / Inclusions is an important step when setting up a project into SonarQube.

Defining Scope of Source Code to Analyze

Defining the scope of the source code to analyze is a three-step process.

1. Source Directory

First, properly set the sonar.sources property to limit source code analysis to what the team can work on (do not analyze libraries and third-party tools source code for example).

2. File Suffixes

Each language plugin also offers a way to restrict the scope to files matching a set of extensions. Go to Settings > General Settings > LanguagePlugin and set the sonar.xxx.file.suffixes property:

3. Excluding Files

It is possible then to exclude some specific files from being analyzed. At project level, go to Configuration > Settings > Exclusions 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 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 and set the sonar.inclusions and sonar.test.inclusions properties.

Exclusions on Coding Rules

 

 

Exclusions on Duplications

  • Exclude some files from being checked against duplications. To do so, set the sonar.cpd.exclusions property (Configuration > Settings > Duplications).

Exclusions on Code Coverage

 

Exclusion/Inclusion Patterns

Path can be defined either as relative or absolute.

The following wilcards can be used:

WilcardMatches
*zero or more characters
**zero or more directories
?one single character

Relative Path

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.

Examples

Absolute Path

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

Examples

 

 

 

WilcardMatches
*zero or more characters
**zero or more directories
?one single character

 

  • Fully qualified name of the component (see red frames below):

    For Java only, replace '.' package separator by '/' and add '.java' extension.

    Examples



  • Absolute path:

    Examples

 

 

 

 

*Match zero or more characters
**Match zero or more directories
?Match a single character
file:Prefix to define a pattern based on absolute path
  • No labels