How to improve scan performance


I have a large project to scan and it takes more than 30min.
As far as I understand, a full scan is always needed since a change, say in a method, can raise new alerts on unchanged code in which the method is used.
However it seems that there is a reduced set of rules that may be executed on unchanged files as opposed to running all the rules.

I use Jenkins with Gitlab plugin and build on push and pull request.

I use the following versions:
SonarQube Version 9.9 build 65466

Thanks for your help,


Hey there.

When performing pull request analysis, you should be able to benefit from a server-side cache if the target branch has been analyzed recently. A user shouldn’t have to do anything to benefit from this, so you are likely already benefiting.

If you can’t share the full logs here, I suggest you dig through and find out what is taking the most time. Here’s a post that can help with that:


The log says:

INFO: Server-side caching is enabled. The Java analyzer will not try to leverage data from a previous analysis.

I followed the steps after running a full scan of the target branch :

  • clone the repo
  • fetch all
  • checkout remote target branch to a new local branch of the same name
  • checkout remote source branch to a new local branch of the same name
  • run the build
  • run the sonar scanner

Thanks for your help,


I think that finding where the full scan takes time is another topic. I want to understand why I’m unable to benefit from the server-side cache on merge request.

I think I might have an idea why it’s not working.
We’re creating feature branches from master but we’re not creating our merge request from feature branch to master, we’re creating them to another branch called integration which is derived from master and contains multiple features.

Also, we’re not using Gitlab CI/CD but we’re using Jenkins with Gitlab plugin. Could that also be the reason?

Thanks for your help,

Is the integration branch regularly being scanned by SonarQube?

Yes it is.

Okay. Then when specifically performing Pull Request Analysis (the build is being populated with sonar.pullrequest.* analysis parameters and the results display under the Pull Requests section of your SonarQube project), the cache of the target branch should get utilized.

I’d still suggest sharing the full analysis logs here, preferably at DEBUG level (sonar-scanner -X) to get a better idea of what’s going on.

I see the pull request section is empty in SonarQube.
I think because I’m not using Gitlab CI/CD, the properties sonar.pullrequest.* are not provided and I have to provide them myself.
With Gitlab plugin, it would be something like:


Ideally, this is all getting filled out automatically if you’re using the Gitlab branch source plugin. SonarQube is checking for the CHANGE_ID and CHANGE_TARGET environment variables.

Thanks for the help, I have no doubt this also works, but I flag my answer as solution as it matches what I’ve tested. Also our Jenkins is a managed instance in which we may not freely add any plugins.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.