Sonarqube exclusions vs sonarlint

SonarQube for IDE IntelliJ Platform
1

Please provide

  • Operating system: Debian 11.5
  • SonarLint plugin version: 10.0.0.76954
  • Programming language you’re coding in: java
  • Is connected mode used:
    • Connected to SonarCloud or SonarQube (and which version): yes, sonarqube 8.7.0.41497

Hello,

we have set sonarqube server side folders exclusions (Administration > Analysis scope > Global source file exclusions, aka sonar.global.exclusions : **/xxx/**/*.java)

These files contains autogenerated java code, for which sonar checks are useless.

a) Running sonar in mvn command line :

  • no warning are raised onto these files
  • Got log : Excluded sources: **/xxx/**/*.java
  • Got log : 58 files ignored because of inclusion/exclusion patterns
  • Checked within the sonar GUI : no warnings at all about the exclude files.
    Fine.

b) Running sonarlint onto intellij, connected to the same sonarqube server (with bindings up-to-date)

  • Right click on project > SonarLint > Analyze with sonar lint => Warning are raised onto these files (which are excluded…)
  • Based on what i know, in connected mode, exclusions are fetched from sonarqube server (from which exclusions are working, refer to point a)
  • No log at all about exclusions onto the sonarlint console within intellij GUI
    => Why these files are not excluded by sonarlint intellij plugin?
    => Notice this is the same when opening a single auto generated file (which is sonarqube excluded) : there are sonar warnings onto this single file (but this file is sonarqube excluded, so no warnings should be reported)

c) Same as b, but with Settings > Tools > sonarlint > Project settings > Tab File exclusions : add **/xxx/**/*.java
=> Same as b
=> I assume this is normal since sonarqube rules have precedence over local settings when running in connected mode

Tough, i do not understand why sonarqube exclusions (which are working in mvn command line) are not handled by sonarlint (point b)
This cause massive false positives sonar warnings inside the intellij GUI for these excluded files, which basically make the plugin not usable…

Is this a sonarlint bug?

Thank you by advance!
Regards

2

Welcome :slight_smile:

i noticed the same behaviour for different Sonarlint versions = 8.1 + 9.0, also after binding to Sonarqube Enterprise 9.9 LTS with a global exclusion and project settings / update local storage

But then i tried

2023-11-08_13h35_14

and then after Analyze All

2023-11-08_13h39_20

it is corrrect, the former issues for files that should have been excluded via sonar.global.exclusions already are now excluded and i see only the two expected issues.

2023-11-08_13h42_18

It seems the cache is not refreshed properly via project settings / update local storage
and analyzing again => the former issues stay as they are.

Only after clear project file issues and analyze again all is fine.
IMO it’s a bug, as updating the local storage for a connected project doesn’t sync the issues
correctly.

Gilbert

3

Gilbert, so many thanks.

  • Indeed “Clear project files” onto the sonarlint tab, then “Analyze all project files” => fix the issue, global exclusions are now correctly handled.
  • But : Project right click > sonarlint / Analyze with sonarlint => Global Exclusions are not handled
5

@ Sonarlint for IntelliJ team

is this “works as designed” and should we create a feature request or is it a bug !?

Gilbert

7

Hi @Dubble_Majax,

Thank you, @anon67236913, for your explanation. This is not wrong, meaning this action effectively includes the exclusion settings, but the reason behind it is a bit different.

This topic was recently discussed here.

There are scenarios where we don’t include the excluded files (whether they come from SonarQube or your IDE settings):

  • The first case is when triggering a manual analysis on the current file
  • The second case is when triggering a report on one or multiple files.

In other cases, the excluded files are taken into account. This means automatic analysis (when opening a file, writing code, committing modifications, etc.) or actions not mentioned above, such as the Analyze All Project Files or Analyze VCS Changed Files actions (the list is non-exhaustive).

This decision was taken long ago, so the user can manually analyze a specific file (with a manual action) even though it is excluded by definition.

This is not something we are currently planning to change, but feel free to submit an idea in our roadmap, we would gladly reconsider this if this is an issue for SonarLint users.

8

Hi Nicolas,

This is ok, because in this case I deliberately select files that I want to scan.

But this case is different

  1. open a project in IntelliJ and choose ‘Analyze with Sonarlint’ via context menu on proiect root or hotkey, maybe i forgot to bind the project before => of course i’ll get a lot of issues

  2. then bind the project to a Sonarqube project

  3. then update local storage
    => the issues stay as they are !?
    I would expect the update would trigger a synchronization with the bound Sonarqube project, means the “wrong issues” should disappear, as they are not existent in the Sonarqube project.

But only after clearing the project files issues and analyze all project files again it is correct.
This manual step of clearing should be part of the sync when i have a binding and update local storage.

The current behavior is not expected and I have already received some questions about it.

Gilbert

9

This is because the action Analyze with Sonarlint triggers a report. A report is ultimately a snapshot in time of some issues raised by SonarLint, we are never trying to update or modify it (the only modification we do on the reports is graying out the issues that are not located anymore).

Even by connecting the project to SonarQube, it is not expected that we should modify the report previously done, and we would expect the user to trigger it again if needed.

Nonetheless, we are still happy to receive feedback and suggestions, and please feel free to correct me if I misunderstood something!

10

Not by connecting / binding alone, but by connecting / binding AND update local storage after that.
The user deliberately triggers a sync with the Sonarqube project and expects
issues local = issues Sonarqube project afterwards, but that’s not the case right now.

13

I understand your point, Gilbert, but the report really is a snapshot. We are not willing to modify it once it has been generated. It might not reflect the SonarQube issues if it had been generated before it was bound and synchronized.

However, I can understand that this is not clear enough, whether because the name “report” does not fit or because of how it is presented. So, thank you for raising this point, we will think about how we can improve this in the future. Once again, if you have any feedback, do not hesitate to share them!

14

Let’s give a practical example.
A new team member wants to participate on an existing project.
He has read the documentation and set up Sonarlint including the connection to the Sonarqube server.

  1. Git clone (the Sonarlint settings are not pushed to Git)

  2. IntelliJ File > Open and import the project from local Git

Sonarlint log shows (README.md is automatically opened and analyzed)

Analysing ‘README.md’…
Found 0 issues and 0 hotspots
Downloaded plugin list in 13ms
[SYNC] Synchronizing analyzer configuration for project ‘xx.xxx.xxx:service’
Downloaded settings in 36ms
[SYNC] Fetching rule set for language ‘cloudformation’ from profile ‘AX-1V8Zl0tucpTfqOX7V’
[SYNC] Fetching rule set for language ‘css’ from profile ‘AW5A8LikBR_Hqfnbjqfi’
[SYNC] Fetching rule set for language ‘docker’ from profile ‘AYcCpEVjP7YYXsi7GElW’
[SYNC] Fetching rule set for language ‘java’ from profile ‘AWeExML6mfcR-ajE9Ebe’
[…]

  1. Bind project to the relevant Sonarqube project

Sonarlint log shows

Clearing all findings because binding was updated
Using connection ‘xxx SonarXX’ for project ‘xx.xxx.xxx:service’
Analysing ‘README.md’…
[SYNC] Synchronizing issues for project ‘xx.xxx.xxx:service’ on branch ‘master’
[SYNC] Synchronizing taint issues for project ‘xx.xxx.xxx:service’ on branch ‘master’
Found 0 issues and 0 hotspots

  1. Choose Update local storage

Sonarlint log shows

Downloaded plugin list in 13ms
[SYNC] Synchronizing analyzer configuration for project ‘xx.xxx.xxx:service’
Downloaded settings in 36ms
[SYNC] Fetching rule set for language ‘cloudformation’ from profile ‘AX-1V8Zl0tucpTfqOX7V’
[SYNC] Fetching rule set for language ‘css’ from profile ‘AW5A8LikBR_Hqfnbjqfi’
[SYNC] Fetching rule set for language ‘docker’ from profile ‘AYcCpEVjP7YYXsi7GElW’
[SYNC] Fetching rule set for language ‘java’ from profile ‘AWeExML6mfcR-ajE9Ebe’
[…]

here i would expect this
[SYNC] Synchronizing analyzer configuration for project ‘xx.xxx.xxx:service’
means from now on i will use the same settings as the Sonarqube project including the
in- / exclusions and the global in-/exclusions for my local scan - after all, that is the purpose of binding !?

  1. Analyze all via context menu on project root folder

Sonarlint log shows

Using connection ‘HUK SonarPR’ for project ‘xx.xxx.xxx:service’
Analysing ‘README.md’…
Found 0 issues and 0 hotspots
Using connection ‘xxx SonarXX’ for project ‘xx.xxx.xxx:service’
Analysing 118 files…
Found 130 issues and 2 hotspots

which is wrong, the global exclusions are not respected, all issues are raised in generated sources.

  1. clear project files issues and use ‘Analyze All Project Files’ from Sonarlint view

Sonarlint log shows
Using connection ‘xxx SonarXX’ for project ‘xx.xxx.xxx:service’
Analysing 90 files…
Found 0 issues and 2 hotspots

=> OK, no issues as expected

Note that after 6. clear project files issues this behaves different

Choose Analyze via context menu on project root

2023-11-16_11h49_30

=> still doesn’t respect the Sonarqube server settings

whereas this works correct

2023-11-08_13h39_20

Everyone expects that Analyze via context menu on project root does the same / is equivalent
to Sonarlint view > Analyze All Project Files

This whole behavior is anything but intuitive and has already caused us many questions and some complaints. IMO it’s buggy.

17

Thank you for the clarification. I understand your point, and this is intended from a purely technical point of view. Analyze with SonarLint and Analyze All Project Files have similar functionalities, but only Analyze with SonarLint does not include the exclusions settings. Thus, the difference in the issues generated by both actions differs, even though this is intended. Ultimately, I agree that the process is very unclear to all users.

I created this ticket. We will try to come up with a better solution to make this situation more transparent. The user should know what to expect from an analysis result, whether the exclusions settings are considered or not.

1 Like
18

Thanks for taking your time and looking into it!
It’s a difference in intention between choosing specific files and ‘Analyze with Sonarlint’ and
‘Analyze with Sonarlint’ via context menu on project root folder.

Use case
Let’s say some developers are working on the same branch. I’m the one doing the final stuff before merging to the release branch. By ‘Analyze with Sonarlint’ via context menu on project root folder i want to check that my changes - and all the changes of my colleagues - won’t break the release build.
To be sure i need / i excpect the analysis using exactly the same settings as the CI build.
Of course i would do an ‘update local storage’ before to sync with the current state of the Sonarqube project.

For a project with a Sonarqube binding i would even bring up a message like i.e.
‘This file is excluded by Sonarqube project | global settings, analyze anyway ?’ when choosing a file / files
that is/are excluded by the project | global settings on Sonarqube server.

Exclusions are not configured without purpose - i.e. generated sources - so scanning those doesn’t make much sense.

1 Like