Message-ID: <1348884612.2181.1432360126436.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2180_268659458.1432360126436" ------=_Part_2180_268659458.1432360126436 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
If SonarQube's results aren't relevant, developers will push back = on using it. That's why precisely configuring what to analyze for each= project is a very important step. Doing so allows you to remove noise, lik= e the issues and duplications marked on generated code, o= r the issues from rules that aren't relevant for certain types of objects.<= /span>
SonarQube gives you several options for configuring exactly what will be= analyzed. You can
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 al= l together to tune your analysis scope.
sonar.sources property to limit the scope of the anal=
ysis to certain directories.
Most language plugins offer a way to restrict the scope of analysis to f= iles matching a set of extensions. Go to Settings > General= Settings > LanguagePlugin and set the File suffi= xes property:
It is possible to exclude specific files from analysis. At the project l= evel, go to Configuration > Settings<= /strong> > Exclusions > Files and set the:=
sonar.exclusions&nbs= p;property to exclude source code files
sonar.test.exclusionsproperty to exclude unit test files
Global exclusions that will apply =
to all projects can also be set. Go to Settings > Ge=
neral Settings > Exclusions > Files and set the
Since version 3.5, you can also work the other way around by setting inc=
lusions. Go to Settings > General Settings > Exclusions =
> Files and set the&=
sonar.test.inclusions properties to the list of files that should be=
analyzed. If you set an inclusion, then only the files or modules listed t=
here will be included in the analysis.
See the Patterns sectio= n for more details on the syntax.
Note that the properties bel= ow can only be set through the web interface because they are multi-valued.=
You can ignore all issues on files that contain a block of code matching= a given regular expression.
Example: Ignore all issues on files containing
You can ignore all issues on specific blocks of code, while continu= ing to scan and mark issues on the remainder of the file.
Note: If the first regular expression is found but not the second one, t= he end of the file is considered to be the end of the block.
Example: Ignore all issues included between
You can ignore issues = on certain components and for certain coding rules.
com.foo, but not in its sub-packages =3D> *;com/foo/*
You can restrict the application o= f a rule to only certain components, ignoring all others.
You can prevent some files from being checked for duplications.
To do so, go to Settings > General Settings > Exclusi= ons > Duplications and set the Duplication Exclusions property. See the Patterns section for more details on the syntax.
You can prevent some files from being taken into account for code covera= ge by unit tests.
To do so, go to Settings > General Settings > Exclusi= ons > Code Coverage and set the Coverage Exclusions property. See the Patterns section for more details on the syntax.
Paths are relative to the project base directory.
The following wildcards can be used:
|*||zero or more characters|
|**||zero or more directories|
|?||a single character|
Relative paths are based on the fully qualified name of the compon= ent (like the one displayed in the red frame below):