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
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:
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?
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:
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.