Unable to suppress sonar issues (tried using sonar-project.properties, systemProp.sonar.* and sonarqube { properties {}})

I’m unclear which sub-system to flag the problem as. I use the sonarqube plugin, but the errors are reported in sonarcloud. I’ll go out on a limb here, and assume that sonarcloud will just show what sonarqube outputs, and that the problem lies with Sonarqube

I’ve tried to follow Configuring a Project to Exclude Certain Sonar Violations | Baeldung
but I can’t get it to work, having tried 3 different ways

  • Top-level sonar-project.properties containing
# ignore method naming checks for logging facades
  • systemProp.* properties in the top-level gradle.properties
# ignore method naming checks for logging facades
  • sonarqube / properties / property for each property in the build.gradle.kts of the project where I want this error to be suppressed
val ruleName: String = "loggingFacadesShouldBeAllowedToHaveWeirdMethodNames"

sonarqube {
    properties {
        property("sonar.issue.ignore.multicriteria", ruleName)
        property("sonar.issue.ignore.multicriteria.$ruleName.ruleKey", "kotlin:S100")
        property("sonar.issue.ignore.multicriteria.$ruleName.resourceKey", "**/LoggingFacade.kt")

To no avail:



Have you tried setting this exclusion via the UI? Right now there are 2 questions: proper configuration of multi-value property; proper configuration of exclusion. Doing this via the UI will eliminate one of them.


This is what I tried in the UI

And I got the same result


I’ve just taken a closer look at your issue screenshots.

You’ve excluded the rule from running on files named LoggingFacade.kt regardless of which directory they’re in. But the issue is being raised not in LoggingFacade.kt but in UseCaseLoggingFacade.kt.

So I guess you’re looking for the pattern **/*LoggingFacade.kt.

As a reminder from the docs

  • * - Match zero or more characters
  • ** - Match zero or more directories
  • ? - Match a single character


You’re correct, when I use that, the exclusion added through the UI works. Thanks for that.

The UI way of doing this is not what I’m looking for though. I would like to achieve this using one of version controllable plain text means I mentioned in the topic subject. Can you speak to those?


Because multi-value properties are tricky to configure, we recommend you do that via the UI. But now that you’ve verified that you’ve got the right pattern, I suppose you can just move it back into your analysis config.


hmm you’re correct, it was incorrect in my initial topic as well. Embarassing. I’ll try that and report.

1 Like

The solution that worked for me in the end was to use systemProp.*s in the top-level gradle.properties

# exclusions

This rule is working using the UI, but not working using the properties approach.

I don’t want to enter anything in the UI, it has to stay in version control, close to the source, in gradle.properties.


What can I possibly have done wrong?


It’s not clear to me why you decided to prefix your property keys with systemProp, but you said it was working so I didn’t question it before.

From the docs it looks like that’s a valid prefix at the gradle.properties level. But not, I think, at the project level.


Yes, it was working for the rule I described in the comment prior (loggingFacadesShouldBeAllowedToHaveWeirdMethodNames). These systemProp prefixed variables are passed on to the JVM daemon that gradle spawns to run the actual command. So that part is working.

Because It works for loggingFacadesShouldBeAllowedToHaveWeirdMethodNames ( kotlin:S100) using the top-level gradle.properties, I expected it to work for common-kotlin:SkippedUnitTests, which it doesn’t. So I’m still stumped.