Where can I find documentation for multi-value properties?

I was recently reading the documentation regarding “Ignoring specific rules from specific files” and was able to successfully configure at least one rule via the UI. However, for better traceability we want to track as much of the configuration as possible in a configuration file in the repository (git on GitHub).

Unfortunately, the documentation states:

The key for this parameter is sonar.issue.enforce.multicriteria , however, because it is a multi-value property, we recommend that it should only be set through the UI.

and does not appear to give any examples or instructions relating to multi-value properties, e.g. searching the SonarCloud docs site for “multi-value” returns exactly 1 match, and it’s the above quoted recommendation not to use them.

Nevertheless, I would like to at least try this. Using “Specifying multicriteria values as properties” and this other post as starting points, it looks like the syntax is something like this:

sonar.issue.ignore.multicriteria=<name-for-entry>
sonar.issue.ignore.multicriteria.<name-for-entry>.ruleKey=<Rule key pattern>
sonar.issue.ignore.multicriteria.<name-for-entry>.resourceKey=<File path pattern>

where:

  • <name-for-entry> is a unique somewhat arbitrary string like myUnusualSpecs
  • <Rule key pattern> specifies the rule to be ignored like c:S125
  • <File path pattern> is a pattern whose matched files will have the rule ignored, e.g. **/vendor/*

and that additional entries can be created by adding another 3 lines having the same format but a new <name-for-entry>.

  1. Is this correct?
  2. Where is it documented?

Hey there.

We don’t document because… it’s complicated and easy to mess up. This is a matter of great debate internally and I have never won the argument to document them.

My advice would be to set these through the UI, run an analysis, and then go check the project-level Administration > Background Tasks, select the analysis and go into the menu that shows Show SonarScanner Context.

You’ll find all the values that get passed to the scanner (that you can recreate in a repo-controlled file) there.

We don’t document because… it’s complicated and easy to mess up.

Wow. I am glad that the GNU make team does not share that flawed and patronizing school of thought. Things that are not trivial are those that are all the more crucial to document. Furthermore, good specifications and documentation are much more than marketing collateral. They are proof that care has been taken to think through the problem domain and help avoid many problematic outcomes, but I digress.

This is a matter of great debate internally and I have never won the argument to document them.

Well, thank you for at least replying to my post here so that I can press on.

You’ll find all the values that get passed to the scanner (that you can recreate in a repo-controlled file) there.

I tried adding the following to my .sonarcloud.properties file, but then they do not appear in the context. Is there some other file that they need to go into instead?

sonar.issue.ignore.multicriteria=exemptAllVendorCode
sonar.issue.ignore.multicriteria.exemptAllVendorCode.ruleKey=*
sonar.issue.ignore.multicriteria.exemptAllVendorCode.resourceKey=**/*stm32g4xx_hal*,**/syscalls.c,**/system_*.c,**/stm32g4xx_hal_msp.c

Only very few settings can be set in a .sonarcloud.properties file (this file is only used for SonarCloud’s Automatic Analysis). Those properties are documented here (and don’t include any multi-value properties): Automatic analysis & SonarCloud

So ultimately, unless you switch to CI-based analysis (and stick a sonar-project.propeties file in the root of your repo with your settings), you’ll have to set these multi-value properties in the UI.

OK, so these would have to be set via sonar-project.propeties instead. Is there an open feature request to improve configurability of automatic analyses? In general, I do not want to write any more actions or consume any more CI minutes than necessary, so I like the “Automatic Analysis” feature. However, I often wish I could do “just a little bit more” with it (e.g., specify target architecture, tweak a few rules, … ). If not, how can I make that request?

When I use the UI it shows context like this:

  - sonar.issue.ignore.multicriteria=1
  - sonar.issue.ignore.multicriteria.1.resourceKey=**/*stm32g4xx_hal*,**/syscalls.c,**
  - sonar.issue.ignore.multicriteria.1.ruleKey=*

but I see that Core/Inc/stm32g4xx_hal_conf.h, which should have matched that resourceKey still has issues flagged, such as c:S125 (“Remove the commented out code.”) Are resourceKey values allowed to have comma-delimited lists of patterns or would I need to explicitly define entries for each pattern? The docs do not show any comma-delimited examples for this field though that is supported for sonar.sources and sonar.tests.

Hey there.

You should have a single pattern rather than a comma-seperated list. So this is the correct interpretation:

Let me flag this thread for the right PMs to take a look at this thread. :slight_smile: