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

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.

Exclusions on Files

Source Directory

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

File Suffixes

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

Excluding Files

It is possible 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