Connected to SonarCloud or SonarQube (and which version): SonarQube 10.6.0.92116
And a thorough description of the problem / question:
Hello, I am looking to use SonarLint with some colleagues and we met a kind of problem concerning the rules.
When we compare the amount of rules triggered on SonarQube and SonarLint, we can see they are less problems on SonarLint
We tried to find the issue, and it seems like the rules that require to check multiple files to be triggered does not work, even if all files concerned are opened
Hello, welcome to the community! And thanks for your question.
This behavior is a current limitation of SonarLint, due to how it is integrated with the IDE.
In most cases, when an analysis is launched in SonarLint (on file open / file changed / file saved), the underlying analyzer will only see the one file being analyzed. However, there are technical solutions that the analyzer could leverage to be aware of other files.
Could you please share which rule(s) are concerned and maybe a minimal reproducer? This could help when discussing the issue with the involved teams.
Okay I looked further into sonarqube / sonarlint errors, and this is going really weird
Sometimes rules aren’t pulled from sonarqube in a file, even if these rules are pulled in other files
Sometimes rules from a category (reliability / maintainability) aren’t pulled in a file even if some of these rules are pulled in other files
For exemple, the rule cobol:SQL.DistinctUsageCheck, is linted in VSCode properly most of the time, but somehow, some files don’t have this rule linted in VSCode while having it detected in SonarQube
(I am on an overall code focus, so it can’t be a problem with new code)
I still found errors which are never detected in sonarlint when it has to check thru different files
Hello, thanks for coming back with the additional data!
As far as I can tell, type-checking rules like S1966, S1967, and S3921 should work normally in SonarLint, provided that the referred copybooks are resolvable in the local file system - see e.g. the screenshots below:
If some of these issues appear in SonarQube but not in SonarLint, I would:
make sure that the folder used as the base directory for the SonarQube analysis is opened as a workspace folder in SonarLint so that (relative) paths can be resolved
double-check that the sonar.cobol.file.suffixes, sonar.cobol.copy.suffixes, and sonar.cobol.copy.directories are correctly set for the project and resolvable in SonarLint
I believe the SQL-related rules should also work, provided that the catalog-related properties are correctly set for the project and that the CSV files are available in the workspace folder.
We didn’t edit these parameters because in the documentation there’s written “The following COBOL analyzer properties are synced by default unless previously overridden locally.”
I tried to change these settings in the /.vscode/settings.json file but there’s 2 problems :
in the documentation there’s written “In case copybooks are in different location locally, the analyzer property sonar.cobol.copy.directories should be defined in the /project/.vscode/settings.json file”
Does it mean I have to make a new settings.json file at path /project/.vscode/ ?
also in the documentation, there is written the parameters to change, but not how to change it, so I couldn’t manage to make it work
Here is what I did :
I believe there are misleading parts in the documentation, I will get in touch with the docs team to clarify things.
When the docs mention /project/.vscode/settings.json, it should be read as ${folder}/.vscode/settings.json, where ${folder} is the path to the workspace folder that is bound to the SonarQube project.
Furthermore, the sonar.cobol.* parameters are not top-level settings in VSCode, they should be set as analysis properties in sonarlint.analyzerProperties (see sample below).
So, if your workspace folder is e.g. in C:\Users\my_user\Dev\my-folder, then:
You should be able to define the properties in C:\Users\my_user\Dev\my-folder\.vscode\settings.json
The syntax to set the values you mentioned is the following one:
It looks like these parameters breaks SonarLint.
I get this with them
[Debug - 08:06:13.046] Execute Sensor: TextAndSecretsSensor
[Info - 08:06:13.046] Available processors: 20
[Info - 08:06:13.046] Using 20 threads for analysis.
[Info - 08:06:13.346] The property "sonar.tests" is not set. To improve the analysis accuracy, we categorize a file as a test file if any of the following is true:
* The filename starts with "test"
* The filename contains "test." or "tests."
* Any directory in the file path is named: "doc", "docs", "test" or "tests"
* Any directory in the file path has a name ending in "test" or "tests"
[Info - 08:06:13.385] Analyzing all except non binary files
[Info - 08:06:13.400] 1 source file to be analyzed
[Info - 08:06:13.470] 1/1 source file has been analyzed
[Info - 08:06:13.476] Analysis detected 0 issues and 0 Security Hotspots in 5203ms
And this without
[Info - 08:16:58.591] Analyzing all except non binary files
[Info - 08:16:58.608] 1 source file to be analyzed
[Info - 08:16:58.683] 1/1 source file has been analyzed
[Info - 08:16:58.689] Analysis detected 2 issues and 0 Security Hotspots in 5543ms
[Debug - 08:16:58.699] Skip downloading file issues on SonarQube
[Debug - 08:16:58.704] Skip downloading file hotspots on SonarQube 10.1+
EDIT :
After some investigation, It looks like the parameter "sonar.cobol.copy.directories" breaks everything.
We have our copies and cobol programs in the same folder, they just get a different file extension
Is it because SonarLint doesn’t analyze copy directories ?
