The task dependence injected by the Gradle Sonar Plugin assumes that the project conforms to idealistic standards and that test coverage is to be included.
However, for projects which do not conform to these standards, or for those which wish to only complete static code analysis, the ‘out-of-the-box’ task dependence can be undesirable.
It would be fairly simple and straightforward (I would be happy to do the work myself) to permit the ‘disabling’ of the automatic task dependence, placing the responsibility of dependency specification on the build script.
Hi Kevin,
I can understand the problem for advanced use cases, so a contribution would be welcome. But before you start, isn’t it possible using Gradle API to disable the task dependency ‘dynamically’ from your build script, without having to introduce a new parameter in the plugin?
Hi @Julien_HENRY,
Although possible we’re concerned with maintainability.
To replicate the desired behavior simply and consistently, one would overwrite all existing dependencies with the tasks they desire.
Suppose the Sonar Gradle project introduces a new (internal) task dependency in an updated release - external task dependency management may (depending on the implementation) then need to take this into account.
Hi Kevin,
What about sonarqube.dependsOn.remove("test") as mentioned here:
Or maybe https://discuss.gradle.org/t/remove-task-dependency/18493
Because the compilation targets are an issue as well.
We still have some compilation occurring in imported ant builds, which breaks the assumed dependency chain on test.
Additionally, I don’t think that will work correctly, or at least consistently, with the way the SonarQube task is configuring it’s dependencies (as a callable) -> https://github.com/SonarSource/sonar-scanner-gradle/blob/master/src/main/java/org/sonarqube/gradle/SonarQubePlugin.java#L92-L96
Sorry for the late answer on this thread, but I have created a ticket to remove this dependency in the next major version of the SonarQube Gradle plugin:
https://jira.sonarsource.com/browse/SONARGRADL-59
The assumed build dependencies remain a major problem for our use case in 2022.
I don’t expect the Sonar Gradle plugin to build my project; I will do that. Sonar should be collating the artifacts and test reports I’ve already produced; for upload to SonarCloud etc. anything else is asking for trouble with more complex use cases. I’ve added a comment here: [SONARGRADL-59] Remove the implicit dependency between 'sonarqube' task and 'test' - SonarSource
Hi @Chris_Hatton,
Welcome to the community!
You’ve resurrected multiple old threads on this topic. Please don’t do that. It would be much better to create a new thread of your own and reference the other topics you’ve found.
I’m closing this thread, but I’ll leave the other one open.
Ann