If SonarQube provides developers with information that 's results are not relevant, they developers will likely push back the toolon using it. That's why configuring the Exclusions / Inclusions for each project is a very important step. Doing so allows you to remove noise (such as , like the issues and duplications marked on generated code or the issues from rules that are not relevant for certain rules on certain types of object) is a very important step..
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
Defining Source Code Scope
Make sure to exclude genearated We recommend that you exclude generated code, source code from libraries, etc. Four There are four different ways are at to narrow your disposal analysis to select the source code that will be relevant to the development team. You can combine them all together to tune your analysis scope.
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. Format 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 use used instead of the module name
It is possible to exclude some specific files from being analyzed. At project level, go to Configuration > Settings > Exclusions > Files and set the:
Switching Off Issues
Set the File Exclusion Patterns property to switch off ignore all issues on files that contain a block of code matching a given regular expression.
Set the Block Exclusion Patterns property to switch off 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 as to be the end of the block.
Example: Switch off all issues included in
BEGIN-GENERATED / END-GENERATED blocks.