Dear SonarSource team,
First of all, congrats on the amazing improvement in Java analysis you managed to implement in SonarQube 9.4!
Now we are using SonarQube Dev Edition 9.5 and it would be great to get a list of the rules that are executed for the untouched Java files in a PR
Before the introduction in 9.4 of the feature to not execute all rules for all classes, my Java analysis used to take almost an hour. Hence, the team decided to implement a mechanism to pass only the touched class as sonar.inclusions, even if we knew that this could result in an issue found only when the PR is merged in the main branch as we weren’t analyzing the unmodified files at all.
However, now that you’ve done something similar (but better!), we’d like to remove our custom workaround and just leave the built-in feature. When testing it, we observed that analyses for PRs take 4-5 min more than the one we implemented, but we were not able to reproduce any scenario in which the analysis failed due to an issue in a non-modified file. Due to this, the team would like to make sure that this change would benefit us to compensate for the increase in execution time.
Therefore, we’d love to have a list of these special rules to come up with a case ourselves, or (even better), get just some basic examples of how to reproduce a bug in a non-modified file.
Looking forward to reading from you!
We upgraded to version 9.6, but we still haven’t observed an improvement in the analysis time compared to the strategy I shared in the previous post.
Do you think there is any reason why we should stop doing it and adopt the standard analysis (without explicitly indicating the classes than changed)? Regarding non-modified files issues detection, we haven’t figured out what could make an analysis fail. Any suggestion on how to try this out? All the feedback is welcome!
Hey there @JesusPajares,
For incremental analysis, it is a bit of a mixed strategy where both changed and unchanged files are always analyzed by:
- All custom rules defined outside of sonar-java
- All the security rules
- All the advanced bug detection rules
Regarding whether you should switch back to standard analysis, keep in mind that while we will keep improving analysis performance of Java code in PRs, no change is likely to be as transformative as the ones we shipped in 9.5 and 9.6.
So it is really up to you to decide if you wish to maintain your current setup or switch to standard analysis.
On the topic of analysis failure, I have not looked much into it but I am not sure your method is going to play nicely with security and advanced bug detection rules that benefit from cross-file analysis.
You may not see it yet because the only issues raised on PRs are on changed files, but these issues are raised based on information gathered during the analysis of the full project.
Thanks a lot Dorian, this really helped has out. We will then go for the built-in solution, as we’ve been able to reproduce some issues is non-modified code after your suggestion