have configured SonarLint in the connected mode to sonarqube server. in the quality profile have only sonarrules (no 3rd party plugins such as Findbugs). but still violation counts are different, means high on the sonarqube server compared to sonarlint. is there any specific reason for this difference?
want to check - in local scanning happens on source code rather than the binary, but in the server it always happens on binary. violation count difference might be due to this reason? please share details
[quote=“G Ann Campbell, post:2, topic:101390, username:ganncamp”]
what is your SonarLint flavor and version? - SonarLint 188.8.131.52308 with Intellij IDEA
what is your SonarQube version and edition - Enterprise Edition and Version 9.9.2 (build 77730)
can you characterize which issues/rules are showing up in SonarQube and not in SonarLint? tried comparing the rules…basically tried exporting the rules (copy and paste) from SonarLint, not very successful. can you guide, what exactly you need to extract and share
There are certain rules that we deliberately don’t run in SonarLint. For instance executing taint analysis rules in the IDE would drag it down, so you’ll only see those issues in connected mode. There are a couple other classes of rules we don’t run in SonarLint, but we recently reorganized the SL documentation & I can’t find the list at the moment. (I plan to raise that internally.)
Thanks a lot, Ann. Much appreciated for the quick response…
will update you tomorrow regarding the missing rules / issues in SonarLint when compared with SonarQube rules execution. in the meantime, if you found the page, which contains this details, please do share
Configured soanrqube with default java sonar rules. Then run code scan for couple of modules in both sonarlint connected mode and sonarqube server. Always sonarlint issues count was higher than sonarqube server. please check the attachment for count details. but done high-level analysis, its scanning the testcases, python and so on. which are additional than sonaqube scan. so, tried exclusions, refer to # 2. please refer to the image below for details
Configured exclusions in SonarLint connected mode for Python,test case and so on. but not working as expected. After configuring exclusions still getting the same issue count in Sonarlint. So, my question "in the connected mode, configured sonarlint exclusions works or not? please confirm.
I’m confused. This started with you reporting that issues were missing on the SonarLint side. Now you’re saying they’re missing on the SonarQube side?
In this (new) case, we would need to look at the SonarQube analysis log. I’m guessing that dependencies that are available in SonarLint aren’t available during the SonarQube analysis, leading to a more thorough analysis on the SonarLint side.
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
found the issue for the issue count difference between SonarLint and SonarQube. Mainly test cases scanning happens in SonarLint, which not happening in SonarQube (exclusion). so, tried to configure exclusion in the SonarQube server to get applied in the SonarLint…so far tried these options without any luck, please help to resolve. Thanks in advance
Configured these in the Global Source File Exclusions
Configured these in the Global Test File Exclusions **/*.java
Enabled Verbose Log. able to see the above SonarQube configure in the SonarLint Log. Looks like Global Source File exclusion is not correct, because issue count is same after and before applying these configurations…
am sure, trying something wrong, please help to resolve. Thanks
Can you try configuring those exclusions at the project level? (Project Settings → General Settings → Analysis Scope)
TBH, the question of applying global exclusions in SonarLint has never come up. It should work, but before we pursue the question of it not working, I’d like to make sure your exclusion patterns do what you expect when configured at the project level.
Thanks a lot, Ann for the quick response, much appreciated
Have tried configuring the exclusions at the project level (Project Settings → General Settings → Analysis Scope) and below are the details
still no change in the issue count. could you please check the configuration and confirm, whats going wrong here…
enabled the verbose log in the IntelliJ IDEA and able to see the exclusion details in the log. but results are the same after this configuration as well
Note - removed Global Exclusion Configuration, while configuring the project level.
The SonarQube file exclusion settings are taken into account in SonarLint when an automatic analysis happens. If you manually triggered an analysis on the current file or if you triggered a report, it won’t take into account the exclusion settings set on your server. It is the same for the SonarLint exclusion settings that you can set within your IDE.
Regarding your question about the difference between **/src/test/java/**/* and **/src/test/java/**, there is none. The ** is already expanding to every file and directory under the current directory, so the last /* should not match anything.
Yes, this is the automatic analysis settings, it is triggered on various occasions, such as opening a file, writing code, compiling, etc.
Could you please try to check if SonarLint analyzes one of your excluded files when you open it? If the file was correctly excluded, the analysis should not happen, and you should be able to see something similar in the SonarLint logs:
File '***' excluded: exclusions configured in the bound project
Server excluded sources:
As I said previously, if you trigger a report, it won’t consider the exclusion settings set on your server. It is the same for the SonarLint exclusion settings that you can set within your IDE. The exclusion settings are only for automatic analysis.
This behavior was made so users could force the analysis on specific files, bypassing the exclusion settings. On any automatic analysis, the exclusion settings should be considered, and you should not be bothered by this file.
This is not something we are currently planning to change, but feel free to submit an idea in our roadmap so this can be considered.