Incremental Analysis

I was wondering if SonarQube Scanner provides a “incremental” Analysis.

My project is growing permanently and we currently have nearly 90 Modules with over 160k LOC (in one project). The analysis takes over 25 Minutes (using SonarQube Scanner).

Regarding the analysis of Git Feature Branches we are thinking about the Developer Edition but such a long running Analysis is a NoGo for our CI Jobs, especially when only a few files have been modified.

I already tried to keep the “.scannerwork” directory with no time improvement and googled for an incremental configuration but only found out that sonar.analysis.mode=incremental is deprecated for a long time now.

Any ideas?


We do not currently support incremental analysis as it can result in less accurate scanning results. This has come up quite regularly, especially in the context of branches and pull requests, and internally there is a lot of discussion around this, but I don’t think we have anything to share at this time.

That said, 25 minutes on 160k LOC seems a little long (although that’s not exactly scientific).

  1. Which side of the analysis is taking so long – the actual scanning or the background task on the SonarQube Server’s side? (If the former, how long is the background task taking to process?)
  2. What version of SonarQube and relevant plugins are you running?
  3. Are you using any plugins that run other analysers (PMD, Checkstyle, Findbugs, etc.)? These are often the cause of lengthened analysis tasks and is rather out of our control.

If you have logs to share from analysis, preferably with debug mode enabled, we might be able to do a sanity check. :slight_smile:


1 Like

Hi Colin,

thanks for the fast reply.
The scanning takes the 25 Minutes.
Background Task on SonarQube is finished in less than 2 minutes, so this is OK.
We’re using SonarQube 7.3 and FindBugs Plugin 3.8.0.

I will check if we’re currently using Rules from the FindBugs Plugin so that I can remove it and retest if it’s faster then.

How can I provide the logs to you if the deactivation does not have the desired effect?


OK since our Profile uses most of it’s rules from Findbugs I can not deactivate it that easy …


You should be able to spot in your logs how long FindBugs is taking. If indeed Findbugs is the cause of long-running analysis, that is something to take up with the plugin developer (if not Findbugs itself, as I think the plugin mostly just wraps Findbugs).

That said, SonarJava is excellent (527 rules and counting), in my opinion.

Perhaps create a second project and assign it the default Sonar Way quality profile and scan your code using that new project key? It would give you an idea of what performance in SonarQube is expected to be like by our standards. You might even find it suitable to use instead of your existing QP. :slight_smile:

Edit: Had to strikethrough, see below

In the event you still wish to share logs, we accept them zipped up and attached to this topic.


OK thanks.
By the way: We are recently working on a QP Switch but it takes some time :slight_smile:


An update. My colleague @ganncamp informed me that when the Findbugs plugin is installed on an instance, it will always run and evaluate all rules, before parsing out the ones enabled in your Quality Profile, so testing performance might not be so simple. :frowning: It looks like an existing issue exists on the sonar-findbugs repo without much traction:

I also forgot to mention that SonarJava does support the import of Findbugs reports (see: MMF-1300) so perhaps it would be possible to stop using the Findbugs plugin, pull out the Findbugs rules from your QP, and run/configure Findbugs seperately and use our native features to import the reports. Just a thought!



1 Like

Hi Colin,

as feedback: I’ve summed up the different “Sensor XXX [xxx] (done) | time=…ms” Log Outputs.

Even if the calculated Total (~36 Minutes) does not equal to the Runtime (~23 Minutes) I have a good Overview what takes the most time:

Java Main Files AST scan (done): 2.8 Minutes
Java Test Files AST scan (done): 0.9 Minutes
JavaClasspath initialization (done): 5.5 Minutes
JavaTestClasspath initialization (done): 5.5 Minutes
Sensor FindBugs Sensor [findbugs] (done): 6 Minutes
Sensor JavaSquidSensor [java] (done): 15 Minutes


Thanks Christoph. Perhaps I should eat my words now since SonarJava appears to be the hotspot here.

Let’s rewind a little bit.

What version of SonarJava are you using?

Debug-level logs (-X) might also reveal more information about what’s taking up the analysis time within SonarJava.


I’m using SonarJava 5.9.1 (build 16423)

Activating the Debug Log I found out that there are tons of jar files analyzied for the classpath.

I managed it to decrease the time dramatically (7 Minutes!) by removing the libraries configuration:**/*.jar**/*.jar

Maybe I need to think about a more precise inclusion of dependencies.

Anyway: Thanks for the help - with 7 Minutes (or less) the Incremental Analysis is not that important anymore.

:tada: That’s great news (and this surely means you will buy our Developer Edition, right? No pressure. :stuck_out_tongue: )



1 Like

Hi Colin,

So you said that you do not support incremental results because they can be less accurate. I am currently working for a company that is transitioning legacy code bases to devops environments with sonarqube. One of my projects is ~250k LOC and takes around a half an hour to be scanned (Contains thousands of errors).

I understand accuracy of results is important, but I think it would be great to provide an incremental scan that could be used by specific build processes, results of which to discard so that they do not mess up the persistent full scan results.

This would allow developers to quickly deploy code to a dev or qa environment and have some sonarqube quality information restricting the full scans to the staging production environments.

You guys have developed a great piece of software but devops is all about streamlining the build and deploy process as well as quality control. Right now sonarqube is conflicting with the first goal.

Even though incremental scan can be less accurate, I’m OK to take the risk. It is better than ~15min scan time that we have now, which makes wastes developers time on waiting (they cannot proceed to merge until the pipeline is successful).

An option to disable expensive checks or to allow incremental scanning would be at least something. This way we’ll be able to do incremental on development branches and full on release branches.

Otherwise product becomes unusable, because codebase will only grow as well as the time taken by analysis.


I just ran into this issue as well.

So far, we used the now removed “Preview” analysis mode with Sonar 6. This mode took less than a minute for PRs on our 250k LOC codebase. After upgrading to Sonar 8 and enabling PR analysis, build times increased by 5 minutes because every build scans the whole codebase. Analysis now takes more time than the whole rest of the CI build including more than 10 thousand tests.

We spent a lot of time to improve our CI builds to get very fast feedback. Preview analysis mode was perfect for this. I think you should reconsider and let users opt-in to incremental analysis again.

For now, we will stay on SonarQube 6.7.

1 Like

Sorry for resurrecting a thread so old, but I read it some time ago and the title is still very inviting.
So in the meantime you released incremental analysis for Java PRs on some SonarQube editions.

Any insight into whether it will be available on Community Edition?

Hi @davidecavestro,

Welcome to the community!

PR analysis isn’t available in Community Edition, so incremental PR analysis won’t be either.


Hello, our company recently upgraded to Data Center Edition Version 9.8 and I am trying to be one of the few to implement this feature “Incremental analysis for Java PRs” in our project build. Can you please point me to the documentation for this or any implementation notes on how can be incorporated in gradle/Jenkins builds?

Hi Mak,

Welcome to the community!

There’s nothing to implement. It’s just part of how it works now.


Wow that’s nice, so we should see PR build times to improve in our Continuous Integration builds with Sonar :slight_smile:

1 Like


After the first full analysis post-upgrade.