Sonar-scanner-gradle incompatible with gradle 9

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)

Gradle - Plugin: org.sonarqube version 6.2.0.5505 (latest)

  • how is SonarQube deployed: zip, Docker, Helm

N/A

  • what are you trying to achieve

Run sonar scanner for gradle with newly released gradle 9.

  • what have you tried so far to achieve this

When running ./gradlew sonar we get the following error:

Execution failed for task ':sonar'.
> Resolution of the configuration ':project-submodule:testCompileClasspath' was attempted without an exclusive lock. This is unsafe and not allowed.

The scanner implementation violates the following: Viewing Dependencies

A task specifies a configuration from another project as an input file collection.

From the error stacktrace I traced it down to the following code path:

This gets called in a loop for each child project:

3 Likes
Error when running sonar task with Gradle 9.0.0-rc-1
3
5

Hi Colin

Thank you for the workaround. It does work, but it comes at a cost of reduced performance. Given that we have 100s of projects, that’s a price we’re not really willing to pay.

It’s also not really feasible to roll this out across all of our projects, as that would be a significant engineering investment to retool our pipelines in the specific case where we invoke the sonar scans, compared to the automated upgrade of a single plugin ID.

6

We’re working on it.

2 Likes
7

Do you guys have a rough ETA. We are paying for Sonar on multiple projects and cannot upgrade to Gradle 9 because of this. It is pretty frustrating we are feeling abandoned a bit by Sonar to be paying for a product, not receiving commercial support, and not given a timeline on that SHOULD have been working at or shortly after the release of Gradle 9. Gradle is not an exotic product, it is used by many many teams. I used to swear by Sonar now the gap is shrinking and I am left wondering if our team should look elsewhere.

2 Likes
8

The goal is by EOM, and I heard yesterday that we’re on track for that!

1 Like
9

Hello everyone,

As we’ve continued working on this project, we’ve encountered some unexpected challenges that have caused us to miss our original end-of-September goal. However, we are actively addressing these issues (see some progress here, merged a day ago) and hope to have an update to share with you very soon. Thank you for your patience and understanding.

1 Like
10

Hey everyone.

We have tagged v7 of the task which supports Gradle 9. More work to support the configuration cache will come later, but the task should no longer crash. I expect the task to be published today or tomorrow, and an official announcement will follow.

11

Here we go!

12

Still having problems with Gradle 9 and the latest Sonar Gradle Plugin (7.0.0.6105):

> Task :sonar FAILED

[Incubating] Problems report is available at: build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

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

For more on this, please refer to https://docs.gradle.org/9.1.0/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
55 actionable tasks: 22 executed, 33 up-to-date

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonar'.
> component2(...) must not be null

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Get more help at https://help.gradle.org.
13

Oh.. in case somebody else is hitting this issue - you might need to switch properties to use providers.getGradleProperty() in the sonarqube {} block.

15

Hi @steve-todorov,
Thanks for sharing this feedback with us. Would you mind creating a separate topic with the property/provider part that was causing issues in the sonarqube block of your build configuration?

It would be really helpful to other users and ourselves, to see if the issue can be prevented in the first place.

Thanks in advance.

Dorian

16

@Dorian_Burihabwa we have some properties which are taken from the environment (i.e. via CI) or from `~/.gradle/gradle.properties`. With Gradle < 9 you could just reference project.findProperty(“myProperty“) or directly use System.getenv. With Gradle 9+ you need to use lazy providers.

Here’s the old code:

        property("sonar.token", project.findProperty("sonar.token") as? String ?:
                                System.getenv("SONAR_PROJECT_TOKEN") ?:
                                providers.gradleProperty("company.sonar.token").orElse("").get())

And here’s the updated version:

        val sonarToken: Provider<String> =
            providers.gradleProperty("sonar.token")
                .orElse(providers.gradleProperty("company.sonar.token"))
                .orElse(providers.environmentVariable("SONAR_PROJECT_TOKEN"))
                .orElse("")

        property("sonar.token", sonarToken.get())

It might be useful if property() can accept a Provider<?> which would allow us to skip calling .get() in sonarToken.get()and be fully lazily loaded.

Not quite sure if we need a new thread for this.

2 Likes
Sonar Community Roundup, November 15 - November 21
17

Hey @steve-todorov,

Thanks again for sharing. I have registered your request in a ticket, which still needs to some work before it can be tackled, and we will revisit the topic in future development cycles.

Cheers,

Dorian