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 14 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. Skip modules

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

You can prevent certain types of issues to be logged on certain files.

File Exclusion Patterns

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


<TODO> Update the screenshot

Exclusions on Duplications

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

Exclusions on Code Coverage

 

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