What's the best way to understand these configuration parameters?

[julian...@gmail.com]

Hi Everyone, 

I've been using using sonar at work on a large project with a large number of developers for over two years. I'm on sonar server 5.5 and sonar-runner-2.5. I'm really thankful for the help this community has provided in the past. 

I'm looking at the following configuration - and I'm making sure I fully understand them. 

(I'm assuming we've all read this doco). 

https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus

Looking at the following - here is how I think these work - please correct me if you've got a better understanding:

sonar.sources - this is the 'base directory of where you want to start scanning'

sonar.test - this is the directory (relative to the sources directory) that the source files for the tests reside

sonar.exclusions - this is the list of files that you want to exclude from the issues list scanning

sonar.coverage exclusions - this is the list of files that you want to exclude from the overage coverage numbers - regardless of whether there is data from them for joco - and regardless of whether they have been included for the issues list in the sonar.exclusions

sonar.test.exclusions - even if a file has been excluded from the issues list above - you can still prompt sonar to read the source and corresponding junit reports and upload them to the sonar server by leaving them out of this list - by putting them in this list - you're excluding the junit report data from being uploaded to the sonar server

Now I might have that wrong - but that's just what I've worked out from trying different parameters. 

My question is: What's the best way to understand these configuration parameters?

Cheers

Julian

[G. Ann Campbell]

Hi Julian,

On Friday, 20 January 2017 12:01:58 UTC+1, julian...@gmail.com wrote:

<snip>

Looking at the following - here is how I think these work - please correct me if you've got a better understanding:

sonar.sources - this is the 'base directory of where you want to start scanning'

Nope. This is the directory, relative to project root, that holds your sources. 

 

sonar.test - this is the directory (relative to the sources directory) that the source files for the tests reside

Nope. This should be relative to project root. As an example, most Maven projects have this structure:

root

|-src

| |-main

| |-test

If I were setting analysis properties for this manually (not that I need to; SonarScanner for Maven handles all that for me!) then I would set 

sonar.sources=src/main

sonar.test=src/test

 

sonar.exclusions - this is the list of files that you want to exclude from the issues list scanning

This can be a list. More commonly, it's a regex, or even a list of regexes.

 

sonar.coverage exclusions - this is the list of files that you want to exclude from the overage coverage numbers - regardless of whether there is data from them for joco - and regardless of whether they have been included for the issues list in the sonar.exclusions

Same note about list vs regex or list of regexes.

 

sonar.test.exclusions - even if a file has been excluded from the issues list above - you can still prompt sonar to read the source and corresponding junit reports and upload them to the sonar server by leaving them out of this list - by putting them in this list - you're excluding the junit report data from being uploaded to the sonar server

Since 6.2, this is not just about what test data is read. Starting from 6.2, files that aren't mentioned in coverage reports are forced to 0 coverage if they contain "executable lines". Listing something here will also suppress that "force 0" behavior as well.

 

Now I might have that wrong - but that's just what I've worked out from trying different parameters. 

My question is: What's the best way to understand these configuration parameters?

Take a look at the docs: https://docs.sonarqube.org/display/SONAR/Analysis+Parameters, and let us know if something there isn't clear.

Ann

[consult...@gmail.com]

Hi Ann,

I found this post trying to understand the sonar exclusions.

Indeed SonarQube documentation is NOT CLEAR at all to me.

 https://docs.sonarqube.org/display/SONAR/Analysis+Parameters

E.g.:

sonar.exclusionsComma-delimited list of file path patterns to be excluded from analysis.

give an example, e.g. src/test/** is valid to leave unit tests out. Their unit test result will still be included I believe?

You mention 'This can be a list. More commonly, it's a regex, or even a list of regexes.'

I doubt that is true or misinformation? It's a file path pattern and not a regular one like on linux, more like one used in jsonpath  /xpath? Please add a link to a concise explanation for the matching syntax/logic, I couldn't find it so far and guessing.

E.g. src/test/** is not regex, that would be src/test/.* and I'd be inclined to ^src/test/.* to ensure the pattern matches the start of the path.

This one is puzzling me today the most:

sonar.test.exclusionsComma-delimited list of test file path patterns to be excluded from analysis.

This will exclude junit results for the matching classes to be uploaded? And as such reduce code coverage? What is the exact purpose of this filter?

Examples examples examples, we are all developers, give some 'most commonly used' real world examples in sonar qube docs, that would make life so much easier for all of us trying to figure out what has changed since version 6 or starting a fresh installation.

Thanks,

Leon

[G. Ann Campbell]

Hi Leon,

Not to split hairs, but since a regex is a sequence of characters that define a search pattern then `src/text/**` is a regex, just not one you're familiar with. :-)

The Analysis Parameters page covers inclusions/exclusions for completeness, but there's actually a whole separate page (linked prominently from the relevant section in Analysis Parameters) that details what kind of patterns will work, and... gives examples!

HTH,

Ann

---

G. Ann Campbell | SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

--
Important: this SonarQube Google Group will close on June 11th, 2018, in order to move to a new forum to power even more community discussions. See details in this post: https://groups.google.com/d/msg/sonarqube/BbSZz-JnhVM/DavhMueEAAAJ
---
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/gqWkitZJFkI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5d7afdca-4bf4-4940-a339-29b1774ce937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Consu Leon]

Hi Ann,

Thanks for the links, I see now that this well documented, I must have found another version of the doc linked via stackoverflow, let me check this out.

Regards,

Leon

On 4 Jun 2018, at 09:01, "G. Ann Campbell" <ann.ca...@sonarsource.com> wrote:

Hi Leon,

Not to split hairs, but since a regex is  a sequence of characters that define a search pattern then `src/text/**` is a regex, just not one you're familiar with. :-)

The Analysis Parameters page covers inclusions/exclusions for completeness, but there's actually a whole separate page (linked prominently from the relevant section in Analysis Parameters) that details what kind of patterns will work, and... gives examples!

HTH,

Ann

---

G. Ann Campbell  |   SonarSource

Product Manager

@GAnnCampbell

https://sonarsource.com

On Sat, Jun 2, 2018 at 2:07 PM, <consult...@gmail.com> wrote:

Hi Ann,

I found this post trying to understand the sonar exclusions.

Indeed SonarQube documentation is NOT CLEAR at all to me.

  https://docs.sonarqube.org/display/SONAR/Analysis+Parameters

E.g.:

sonar.exclusionsComma- delimited list of file path patterns to be excluded from analysis.

give an example, e.g. src/test/** is valid to leave unit tests out. Their unit test result will still be included I believe?

You mention 'This can be a list. More commonly, it's a regex, or even a list of regexes.'

I doubt that is true or misinformation? It's a file path pattern and not a regular one like on linux, more like one used in jsonpath  /xpath? Please add a link to a concise explanation for the matching syntax/logic, I couldn't find it so far and guessing.

E.g. src/test/** is not regex, that would be src/test/.* and I'd be inclined to ^src/test/.* to ensure the pattern matches the start of the path.

This one is puzzling me today the most:

sonar.test.exclusionsComma- delimited list of test file path patterns to be excluded from analysis.