I run detekt, run the tests with jacoco for coverage. All is well. Then it’s time for sonarqube task to upload the data I’ve collected, and this step takes forever - 200 seconds when a handful of seconds is what I expect given the amount of data to upload. I assume it tries to do some kind of source code analysis on its own before uploading things as if I disable detekt there are still some issues presented in the UI. Is there any way to disable this? I’ve managed to squeeze down my CI time from ~11 minutes to to ~5 minutes the past few weeks. It’s going to be a hard sell to introduce a step that takes 200 seconds at the end of the build without adding any real value.
Hi,
You’re not going to be able to disable the built-in analysis. Have you taken a look at the results of that analysis to see how they compare to what you get from detekt? Because we believe that our analysts adds a good bit of value.
HTH,
Ann
The execution time is just too much. But I realize now that the gradle plugin is open source so I can just vendor it under buildSrc and exclude the embedded scanner it looks like.
Hi,
How many lines of code are we talking about?
Ann
Not that much, ~80kloc Kotlin being analyzed (unless the embedded scanner also looks at the JOOQ Java files which is another 55kloc). But adding a sequential 200 seconds CI step to a highly parallellized build that without sonar scanner takes 300 seconds wall clock time is a bit much. Is it possible to reduce the time by caching something between CI runs?
Buhuu… so the scanner is also what uploads the detekt reports… 
Hello,
As you understood, the “SonarScanner” is there first to run rules provided by SonarCloud to analyze your Kotlin, and Java code (actually all the languages we support).
Then on top of that, you can load external analyzer results such as Detekt or coverage data.
If you really don’t see any value in running our Kotlin and Java rules in your code, then you can still do that:
- create an empty Kotlin quality profile
- create an empty Java quality profile
- associate these profiles with your project
… to save some precious seconds by not having the corresponding rules running.
For 80+55 KLOCs, our expectation is to have the scanner running in less than 6 min, so your 200 seconds are in the acceptable range we set for ourselves.
In the coming months on SonarCloud, we should be able to enable a cache mechanism first on PR and then on Branch analysis that will speed up analysis so we could meet your speed expectations. Here is the corresponding card in SonarCloud’s portal.
Alex
1 Like
I must be missing something. I did as you suggested and created two empty profiles and activated them on the project I’m working with. I then re-executed ./gradlew sonarqube but the gradle task still takes about the same amount of time. I was expecting sonarqube task to take a handful of seconds or how long it might take to upload my detekt/coverage/test reports after disabling the scanning. Should that be enough? Also saw some random mentions of sonar.profile property, but setting that to my new kotlin profile didn’t help either. And as hinted in the earlier message… I don’t expect the Java sources to take any amount of time as they are 100% auto-generated and makes no sense to spend any CPU-time on, I don’t add any paths with Java sources so I hope no Java scanning is going on.
Hi Daniel,
I am running into the same issue as you described. Could you please provide more detail in exactly how you exclude the embedded scanner?