which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube Enterprise 7.4.0.18908
Scanner 3.2.0.1227
SonarQube Gradle plug-in 2.7
what are you trying to achieve
I am trying to scan my codebase, but trying to run all my tests sequentially takes too long and times out. We already run our tests in batches in parallel.
I’m trying to disable running tests during the Gradle sonarqube task.
In fact this question was also raised internally. I think we’re going to drop the dependency, altho I don’t have a ticket number to give you right now. In the meantime, this workaround was suggested: sonarqube.dependsOn.remove("test")
Thank you, Ann. I’m looking forward to that change.
The dependency on test makes a lot of sense on a well-factored codebase with fast tests, but it collides badly with our monolithic codebase with its huge, slow testsuite
Has the workaround been validated?
I got this when I tried it:
17:39:29: Executing task 'sonarqube'...
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy UP-TO-DATE
> Task :buildSrc:processResources UP-TO-DATE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE
> Task :buildSrc:assemble UP-TO-DATE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build UP-TO-DATE
FAILURE: Build failed with an exception.
* Where:
Build file '/Users/example/Documents/work/example/build.gradle' line: 24
* What went wrong:
A problem occurred evaluating root project 'example'.
> Could not get unknown property 'dependsOn' for object of type org.sonarqube.gradle.SonarQubeExtension.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1s
Could not get unknown property 'dependsOn' for object of type org.sonarqube.gradle.SonarQubeExtension.
17:39:30: Task execution finished 'sonarqube'.
I did something significantly more invasive to work around this and something direct like that would be a big improvement.
I added this to each project:
test.exclude '**/**'
task realtest(type: Test, description: 'Runs the tests.', group: 'Verification') {
include '**/**'
}
Okay, you caught me. That workaround was tossed out in an internal thread, but no one chimed in to say “yeah, that!”. I passed it on hoping that the lack of a “no!” was a “yeah, sure”. Sorry I caused you extra trouble with it & glad you did find a solution.
on a more serious note … we are actually experiencing this, too … i am currently challenging our build engineers with what i need to upgrade SonarQube from 8.9 (java11 optional) to 9.x (java11 mandatory)
The documentation here explains a (Jenkins) way for maven (but not for gradle) and the challenges mentioned here in this thread surface in our builds. (the gradle task dependencies, even optimized already, need some -x administration)
If anything, would it maybe be possible to address the documentation of working ways for both tools (maven + gradle) in the beforementioned existing docs?
it would be nice to be able to use that as a reference for ppl asking
The fact that the sonarqube task implies any other build/test related task dependencies of its own is a disaster for our use case. We have a CI setup where binaries are build, Unit Tests are run and Coverage Reports compiled already before sonarqube is run. My expectation is that Sonar Scanner will minimally parse the existing resources and not wastefully compile the whole project again: With no solution this will add 10 minutes to each build that we run dozens of times a day… actually a significant economic impact for the company where team members often need the results from builds to continue their work.
Any advice on how to prevent re-test/build greatly appreciated.
i actually have not seen this kind of “task dependency manipulation” before, thank you for documenting it here (but i think, i’d much rather not like to have to work against such an expectation-management, i guess )