The only solution we have to save thoses ~18min is to drop sonar in profit of alternative tools like gitlab SAST or github CodeQL.
(most of sast scanners can run in parallel of our build step… except spotbugs that need a compilation)
I don’t find any good reasons why sonar scan is dependent of the coverage.
Maybe you should reconsider fixing this issue ?
Interesting how different the aproaches are between the various languages unfortunately the Java analysis works different. There’s only one step that you call after everything was done.
# your build and unit test
./gradlew build
# our special integration tests
./gradlew integrationTest
# only now you can start sonar
./gradlew sonar
but what is desired is something like this:
./gradlew build
# just writing this the shell way to get the idea of cause we would do more serious synchonization
./gradlew sonarCodeAnalysis &
./gradlew integrationTest
./gradlew sonarReporting
We actually dropped test coverage reporting entirely to sonar because this takes too long.
I second @ggjulio 's opinion that we should be able to split sonar-scanner in 2 stages:
static analysis
publishing the results.
Ideally we would love to be able to run Sonar in CI pipelines with parallel stages. This would allow us to have our unittests to compile and run in some stages, while sonar is executing the static analysis in multiple stages (one stage per language), the sonar analysis stages then stash the report files and at the end of the pipeline we have a final sonar stage that will:
aggregate the test results, coverage reports, static analysis from other tools (such as golangci-lint), the static analysis from the sonar analysis stages.
publish that to the Sonar backend
This approach would shave 10m or more per CI pipeline for many customers, especially customers with larger repos. As long as the git hash is consistent across all the stages, this should not be too difficult to implement.
We have another, but similar, use case. After build we kick of integration tests that runs separately, this is due to the time it takes to finish. In the end we would like to merge scanner analysis, coverage from unit tests and integration tests into the same analysis.
We’re facing the same dilemma-- a large ruby codebase running the test in 60+ parallel groups already taking 20+ minutes each. If we can only run SonarQube’s static code analysis and sending code coverage together, it adds an extra 20 minutes after the initial 20 minutes.
If we’re able to split the analysis in a separate step, we can run it parallel with the unit test executions and collection of code coverage.
The same issue for us.
We have a large Rails codebase and use parallel CI workers to run specs. We do Rubocop/Brakeman/ESLint analysis in parallel with spec workers, so it adds no time. After workers complete (~15 minutes), we run a dedicated step that merges all coverage reports and sends them to CodeCov (it takes less than a minute).
Then we have added SonarCloud. But because it’s impossible to split the “analysis” step (which takes ~10 minutes on the main branch) and the “send coverage” step, we must run the complete SonarCloud scan + send coverage after spec workers complete, which adds ~10 minutes to the CI build time. So, instead of ~15 minutes in the past, now our CI build takes ~25 minutes, which is very frustrating, and we don’t have any way to overcome it.
Adding more cores/RAM for SonarCloud has no effect, as the scanner utilizes only one core for 90% of scan time.