Sonar.issue.ignore.multicriteria enhanced ruleKey configuration

  • SonarQube Server Enterprise 2025.1 LTA (sonarqube-2025.1.2.108896)
  • Deployment by zip
  • SonarScanner 5.0.1.3006
  • Linux 5.4.0-186-generic amd64
  • build-wrapper, version 6.62.2 (linux-x86_64)
  • CPP cfamily plugin used

Is it possible to have a more enhanced ruleKey configuration for sonar.issue.ignore.multicriteria ?

So for example instead of configuring

ruleKey=CPP:S3584

to ignore this issue in general for all configured resourceKeys, can we also configure something like

ruleKey=BLOCKER:MAJOR:GLOB/ObjectManager*:CPP:S3584

to ignore this issue not in general for all configured resourceKeys, but only for certain severities like BLOCKER and MAJOR and for certain classes like GLOB/ObjectManager* in c++ sources?

Hi,

It’s not clear to me why you would need this.

This type of exclusion can be set at the global level, but it should typically be set at the project level. There can only be one Quality Profile per language for any given project. So within that project, you shouldn’t need to specify severity variations for a rule. Just exclude the rule if the profile for your project has it at that severity. Does that make sense?

 
Ann

Thank you. Regarding severity, you are right, this doesn’t make really sense and I discussed this in our team.

To make it more clear, our use case is to ignore rules like CPP:S3584 not for all resourceKeys (c++ source files), but only for certain classes within such resourceKeys.

So for example, we would like to configure this (by UI or by properties file):

sonar.issue.ignore.multicriteria=e1
sonar.issue.ignore.multicriteria.e1.ruleKey=GLOB/ObjectManager*:CPP:S3584
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*.cc

So rule CPP:S3584 should affect all .cc source files, but only for any C++ classes named GLOB::ObjectManager where ‘*’ is a wildcard character.

Hi,

Assuming a “resource key” is a file path, you can do exactly that, but not quite as you’ve specified. Try something like this:

 
HTH,
Ann

Refering to the example if this class GLOB::ObjectManager* would be separated in source files, you are right. But this is not the case. It is a class name used in different c++ sources which are not in a file path GLOB/ObjectManager*/**/*.cc.

Hi,

Okay, well I was obviously guessing. The point is that no part of the file spec goes in the ruleKey value.

 
HTH,
Ann