SonarScanner for Gradle 7.4.0.8496 analysis failing

SonarQube Cloud
1

Hi,

I believe this is the same underlying issue as SCANGRADLE-293, but with a standard JVM java-library source set rather than Jandex.

Environment:

  • SonarScanner for Gradle 7.4.0.8496
  • Gradle 9.4.1
  • JVM project using java-library

Reproducer is on GitHub - bc-lee/sonarqube-gradle-jvm-resolver-poc: sonarqube-gradle-jvm-resolver-poc · GitHub .

With a java-library JVM module and a resource file in src/main/resources, running:

./gradlew :probe-lib:processResources :probe-lib:sonarResolver \
  --no-configuration-cache

fails because :probe-lib:sonarResolver consumes
probe-lib/build/resources/main without a declared dependency on
:probe-lib:processResources.

Gradle 7.6.4 reports this as a deprecation warning and succeeds; Gradle 9.4.1
fails the build.

The project-side workaround is analogous to the Jandex workaround:

tasks.named('sonarResolver') {
    dependsOn tasks.named('processResources')
}

However, that requires knowing each producing task. Would this be considered a
regression of SCANGRADLE-293, and should that ticket be reopened?

2

I confirm the problem with 7.4.0.8496, all our sonar tasks are failing since yesterday

Gradle 9.6.1 here

 Task ':query:sonarResolver' uses this output of task ':query:processResources' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed





    For more information, please refer to 
 in the Gradle documentation.


You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.


    Possible solutions:


      1. Declare task ':query:processResources' as an input of ':query:sonarResolver'.


For more on this, please refer to 
 in the Gradle documentation.


      2. Declare an explicit dependency on ':query:processResources' from ':query:sonarResolver' using Task#dependsOn.


34 actionable tasks: 22 executed, 12 from cache


      3. Declare an explicit dependency on ':query:processResources' from ':query:sonarResolver' using Task#mustRunAfter.
4

Hi @bc-lee and @stephane-barbaray_ec,

Thank you for the heads up, let me try the reproducer.

5

Hello again, I could reproduce the bug and we will start working on a fix shortly.

7

I’m facing a similar problem in my JVM only modules on a KMP project. It was introduced by latest gradle plugin release (7.4.0.8496).

Gradle detected a problem with the following location: './subdependency/build/libs/subdependency-jvm.jar'.

Reason: Task ':app:desktop:sonarResolver' uses this output of task ':subdependency:jvmJar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

As the sonarqube sonarResolver task depends on the generated jar files from submodules and does not declare the dependency on the jvmJar task of those modules, the build is failing. Not sure if the investigation will cover this case given it seems to have the same root cause.

My workaround was adding:

    tasks.withType<SonarResolverTask>().configureEach {
        val jarTasks = tasks.findByName("jvmJar")
        if (jarTasks != null) {
            dependsOn(jarTasks)
        }
    }
8

This issue was introduced by a change I made in PR #517. Sorry for the regression.

I have opened a new PR #532 to fix it by preserving classpath producer dependencies in sonarResolver.

If you have encountered similar issues, please let me know so I can add additional regression tests to cover those cases. Thanks.