Kotlin-dsl multimodule kotlin project analysis detects all modules, but imports them all with the same (nondeterministic) name

When I gradle sonarqube on a kotlin-dsl multimodule kotlin project , all the sub-modules that should be analyzed are detected:

$ ./gradlew sonarqube --dry-run | grep sonarqube
:logging-api:sonarqube SKIPPED
:logging-core:sonarqube SKIPPED
:logging-examples:sonarqube SKIPPED
:logging-recipe-proxylogger:sonarqube SKIPPED
:logging-sink-inmemory:sonarqube SKIPPED
:logging-sink-printstream:sonarqube SKIPPED

So far, so good. But when I actually run it, and then look in Sonarcloud, I get 6 background tasks for the exact same project name. I don’t want to have to touch every module to add extra sonarQube properties when everything is already part of the gradle object model.

Because there is no actual example of a kotlin-dsl multimodule kotlin project in your github repo, I had to look somewhere else, and even trying to add

sonarqube {
    properties {
        property("sonar.projectName", "xxxxx-logging:${project.name}")

Leads to the same outcome. In fact it’s even worse, because the name under which all background tasks are created looks non-deterministic (in my example it’s now proxylogger).

I use org.gradle.parallel=true as a matter of course. So maybe that is not supported.

If I deactivate parallelism, I still get confusing output. The gradlew sonarqube command tells me the quality gate is FAILED, but the background task says SUCCESS.

Can someone on your end actually go through the motion of creating a working kotlin-dsl multimodule kotlin project scanning example, and share it for our benefit?

This takes 5 minute to generate such a project with gradle init:

$ gradle init
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

Select type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 2

Select implementation language:
  1: C++
  2: Groovy
  3: Java
  4: Kotlin
  5: Scala
  6: Swift
Enter selection (default: Java) [1..6] 4

Split functionality across multiple subprojects?:
  1: no - only one application project
  2: yes - application and library projects
Enter selection (default: no - only one application project) [1..2] 2

Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Kotlin) [1..2] 2

Project name (default: example): multimodule-kotlin-dsl-kotlin-project
Source package (default: multimodule.kotlin.dsl.kotlin.project):

> Task :init
Get more help with your project: https://docs.gradle.org/6.8.3/samples/sample_building_kotlin_applications_multi_project.html

2 actionable tasks: 2 executed


I figured that I had a projectKey in the top-level gradle.properties. So every module was using that, trampling over each other’s feet. It would be better if there was an error message like “concurrent projectKey submission error”.

But I still find confusing that I get

QUALITY GATE STATUS: FAILED - View details on https://sonarcloud.io/dashboard?id=xxxx-logging%3Alogging-api

And when I go there, and look at the background tasks overview, the last task is SUCCESS.

Are the status column in the background tasks overview and quality gate status two different concepts?

Hello @pebble_statue

Thanks for your message and indeed you should have different project keys for different projects.

As for your question. As fas as I can say from your screenshots, previously you had a failed analysis in some projects. This means that sth went wrong during analysis itself and it ended exceptionally.

Quality Gate is a different thing. Your project was successfully analyzed. And according to the gathered metrics and your requirements for (maintainability, reliability, security etc) there is a mismatch. Failed QG is a normal situation. It just means that we found some issues in your projects and you can improve it. You can find more about Quality gates here.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.