Sonar Gradle Plugin v7.2.+ not supporting wildcards in path

SonarQube Server / Community Build
,
1

Hi :waving_hand:

I’ve just upgraded my Sonar Gradle plugin and the behaviour has changed and I’m not sure how to get it to work, or whether this is a bug.

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)
    • Sonar Scanner Gradle Plugin v7.2.0.6526 (and above)
    • Sonar Scanner Gralde Plugin v7.1.0.6387 (and below) works as expected
  • how is SonarQube deployed: zip, Docker, Helm
    • N/A
  • what are you trying to achieve
    • Use wildcards in sonar.coverage.jacoco.xmlReportPaths
  • what have you tried so far to achieve this
    • Downgrading to previous version

With configuration:

sonarqube {
  properties {
    property("sonar.coverage.jacoco.xmlReportPaths", "${rootDir}/**/build/reports/kover/report.xml")
  }
}

I get this error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonar'.
> Illegal char <*> at index 29: <path>/**/build/reports/kover/report.xml
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':sonar'.
...
Caused by: java.nio.file.InvalidPathException: Illegal char <*> at index 29: <path>/**/build/reports/kover/report.xml
        at org.sonarqube.gradle.SonarTask.lambda$filterPaths$8(SonarTask.java:401)
        at org.sonarqube.gradle.SonarTask.filterPaths(SonarTask.java:402)
        at org.sonarqube.gradle.SonarTask.lambda$filterPathProperties$5(SonarTask.java:377)
        at org.sonarqube.gradle.SonarTask.filterPathProperties(SonarTask.java:376)
        at org.sonarqube.gradle.SonarTask.run(SonarTask.java:164)

I tried to have a quick look at the diff between versions and saw the addition of java.nio.file for filtering paths, which looks like it’s the culprit. But I’m not sure whether I need to do something different (preferably not avoiding wildcards) or whether wildcards can be resolved before they get to this step, or something else.

Thanks in advance to anyone that can have a more informed look.

1 Like
2

Hello and thanks for your feedback!

It does look like a regression introduced in 7.2. I’ve created a Jira ticket to track our work on it, and I’ll keep you updated.

3

Hello,

We just released a new version 7.2.2 which includes a fix for the wildcard issue.

Please upgrade to that version and let us know if you are still experiencing issues.

2 Likes
4

Hello Romain,

Can confirm that has resolved the issue.

Thanks so much for the quick identification and resolution, really appreciate it!

1 Like
5

Unfortunately, it did not solve the issue for me, my lines of code dropped to 0 when I updated the plugin from 7.1.0.6387 to 7.2.0.6526 and the new release (7.2.2.6593) does not help.

I have SonarQube Enterprise Edition v2025.4.3 (113915) on server-side

It’s a multi-module project. Root config looks like this:

sonar {
   properties {
      property(“sonar.exclusions”, “**/BuildConfig.class,**/R.java,**/R\$*.java,src/main/gen/**/*”)
      property(“sonar.sources”, “src/main”)
      property(“sonar.tests”, “src/test”)
      property(“sonar.coverage.exclusions”, “build.gradle.kts”)
      property(“sonar.coverage.jacoco.xmlReportPaths”,“${buildDir}/reports/jacoco/jacocoTestReport/jacocoTestReport.xml”)
      property(“sonar.junit.reportPaths”, “${buildDir}/test-results/”)
      property(“sonar.androidLint.reportPaths”, “${buildDir}/reports/lint-results-debug.xml”)
   }
}

subprojects {
   sonar {
      properties {
         property(“sonar.exclusions”, “**/BuildConfig.class,**/R.java,**/R\$*.java,src/main/gen/**/*”)
         property(“sonar.sources”, “src/main”)
         property(“sonar.tests”, “src/test”)
         property(“sonar.coverage.exclusions”, “build.gradle.kts”)
                property(“sonar.coverage.jacoco.xmlReportPaths”,“${buildDir}/reports/jacoco/jacocoTestReport/jacocoTestReport.xml”)
         property(“sonar.junit.reportPaths”, “${buildDir}/test-results/”)
         property(“sonar.androidLint.reportPaths”, “${buildDir}/reports/lint-results-debug.xml”)
      }
   }
}
8

Hey @Tyrannoseanus and @Alix,

Sorry for the late reply, we have identified the issue and will be working on a fix but in the meantime, the recommendation is to downgrade to version 7.1 of the scanner.

Sorry for the inconvenience and thank your for your patience.

Cheers,

Dorian

1 Like