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

Table of Contents

If SonarQube's results are not relevant, developers will push back on using it. That's why configuring the Exclusions / Inclusions 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 are not relevant for certain types of object.

SonarQube gives you several options for configuring exactly what will be included / excluded. You can

  • completely ignore some files or directories
  • exclude files/directories from Issues detection (specific rules or all of them) but analyze all other aspects
  • exclude files/directories from Duplications detection but analyze all other aspects
  • exclude files/directories from Coverage calculations but analyze all other aspects

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 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), it is the artifactId that should be used instead of the module name

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

Known limitation in .NET: this property does not currently work while the "sonar.dotnet.key.generation.strategy" is set to "safe". See SONARDOTNT-10.

File Suffixes

Most language plugins offer 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 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.

See the Patterns section for more details on the syntax.

Ignore Issues

You can have SonarQube ignore issues in files or in sections of file by file content, by file path pattern, or both. See the Patterns section for more details on the syntax.

<TODO> Include UI path to these settings

Ignore Issues on Files

Set the File Exclusion Patterns property to 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

Set the Block Exclusion Patterns property to 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 in GEN-FIRST / GEN-LAST or BEGIN-GENERATED / END-GENERATED blocks.

Ignore Issues on Multiple Criteria

Set the Multi-criteria Exclusion Patterns property to ignore all issues on specific components, coding rules and line ranges.

Examples:

  • I want to ignore all kinds of issue on all files => **/*;*;*
  • I want to ignore all issues on COBOL program bank/ZTR00021.cbl => bank/ZTR00021.cbl;*;*
  • I want to ignore all issues on classes located in the Java package com.foo => com/foo/*;*;*
  • I want to ignore all issues against coding rule cpp.Union on files in directory object and its sub-directories => object/**/*;cpp.Union;*
  • I want to ignore all issues on all files on several line ranges => *;*;[1-5,15-20]
     

    <TODO> Update the screenshot

Include Issues on Multiple Criteria

Inclusions allow you to ignore everything but a certain pattern. Say that your profile includes the Magic Number rule, but you only want it to run against files with Bean in the name. Inclusions give you the ability to do that. In essence, they allow a negative exclusion pattern. Here's one way to think of it:

exclude Magic Number on ![**/*Bean.java]

Which means, that Magic Number will be executed on files that end with Bean, but no others. Of course, the actual syntax is a bit different.

Use cases:

  • I just want to check the rule Magic Number on Bean objects => **/*Bean.java;checkstyle:com.puppycrawl.tools.checkstyle.checks.coding.MagicNumberCheck;*
  • I just want to check for issues on COBOL programs located in directories bank/creditcard and bank/bankcard => two criteria to define: bank/creditcard/**/*;*;*   and  bank/bankcard/**/*


<TODO> Update the screenshot

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 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 on the syntax.

Patterns

Paths can be defined either as either relative or absolute. Use relative path whenever possible.

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

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

Relative Path

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 ".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.
 

Examples

Absolute Path

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

Examples
  • No labels