We are currently using SonarQube 7.5 and SonarLint 4.0.0.
We have noticed that at times some rule violations appear in code and are reflected in the SonarQube server after analysis but never show up in SonarLint. These are “squid” rules, not PMD, etc, so we fully expect to see them in Eclipse via SonarLint.
We have checked the bindings and they are set up correctly. We’ve also done re-analysis. We have checked SonarLint settings: There are no file exclusions or rule exclusions that are different from those of the bound SonarQube server. Nothing shows up.
I don’t know where to look for any SonarLint log files or anything like that.
I would appreciate some help in debugging this issue, as it’s really causing problems for our developers who rely on SonarLint to help them get ahead of any issues they may have.
First thing that come to my mind is the classification of test/main source files. In SonarQube it is controlled by the scanner. For example the scanner for Maven will get that from the POM (usually src/main/java vs src/test/java).
In SonarLint Eclipse it is different since Eclipse wasn’t making a difference between test and main source files (it has changed in Oxygen, but we only take advantage of that since SonarLint 4.1). There is a configuration parameter with a regexp to differentiate main vs test files.
Please check that the file where the issue is not reported is not wrongly classified as a test file. As a reminder, most rules are not executed on test files.
Also it could be helpful if you could give a reproducer (sample project + source code + the offending rule key).
Hi @Julien_HENRY, how would I check that the file is not wrongly classified as a test file in SonarLint?
Where would I see the configuration parameter?
@Julien_HENRY, thanks for the instructions on SonarLint console and verbose mode. When I analyzed the file, I got the following. Is this a bug?
Forced to init a physical file
java.lang.Exception
at org.sonarlint.eclipse.core.internal.jobs.EclipseInputFile.initFromFS(EclipseInputFile.java:70)
at org.sonarlint.eclipse.core.internal.jobs.EclipseInputFile.getPath(EclipseInputFile.java:64)
at org.sonarsource.sonarlint.core.container.analysis.filesystem.SonarLintInputFile.path(SonarLintInputFile.java:114)
at org.sonarsource.sonarlint.core.container.analysis.filesystem.SonarLintInputFile.file(SonarLintInputFile.java:105)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at org.sonar.plugins.java.JavaSquidSensor.toFile(JavaSquidSensor.java:106)
at org.sonar.plugins.java.JavaSquidSensor.getSourceFiles(JavaSquidSensor.java:98)
at org.sonar.plugins.java.JavaSquidSensor.execute(JavaSquidSensor.java:93)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.executeSensor(SensorsExecutor.java:81)
at org.sonarsource.sonarlint.core.analyzer.sensor.SensorsExecutor.execute(SensorsExecutor.java:72)
at org.sonarsource.sonarlint.core.container.analysis.AnalysisContainer.doAfterStart(AnalysisContainer.java:132)
at org.sonarsource.sonarlint.core.container.ComponentContainer.startComponents(ComponentContainer.java:125)
at org.sonarsource.sonarlint.core.container.ComponentContainer.execute(ComponentContainer.java:110)
at org.sonarsource.sonarlint.core.container.standalone.StandaloneGlobalContainer.analyze(StandaloneGlobalContainer.java:147)
at org.sonarsource.sonarlint.core.StandaloneSonarLintEngineImpl.analyze(StandaloneSonarLintEngineImpl.java:89)
at org.sonarlint.eclipse.core.internal.jobs.StandaloneSonarLintEngineFacade.runAnalysis(StandaloneSonarLintEngineFacade.java:76)
at org.sonarlint.eclipse.core.internal.jobs.AnalyzeStandaloneProjectJob.runAnalysis(AnalyzeStandaloneProjectJob.java:55)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.run(AbstractAnalyzeProjectJob.java:397)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.runAnalysisAndUpdateMarkers(AbstractAnalyzeProjectJob.java:205)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.doRun(AbstractAnalyzeProjectJob.java:167)
at org.sonarlint.eclipse.core.internal.jobs.AbstractSonarProjectJob.runInWorkspace(AbstractSonarProjectJob.java:44)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)
Found 0 issue(s)
Done in 254 ms
I do have a similar problem, but i was wondering if sonarlint was purely relying on rules.sonarsource.com. Thence if we have a quality profile (on a sonarqube instance which is linked to sonarlint) that have a mix set of rules, some existing on rules.sonarsource.com and others that are existing on sonarqube but not par of rules.sonarsource.com, it will not use them. Am i correct ?
Hi @ntriquenaux. It depends. If you have developed custom rules based on the engine of a SonarSource analyzer (for example for SonarJava) SonarLint can execute them. But if you have installed SonarQube plugins running third party code analyzers (like PMD, checkstyle, …) then SonarLint will not execute them.
@Julien_HENRY: Thanks for the answer. All the rules i was interested in are provided by Pylint (as said by the rules repository tooltip in sonarQube). So for these kind of rules sonarLint will not execute them ?
Here is a screenshot of the rule i wanted to have with sonarLint (throught its binding to our sonarQube server)
Hi @Julien_HENRY, here’s more info (uploaded) I don’t know where the full log file resides (or whether it exists), so I attached the full verbose output as of the beginning of analysis of that file, until the end. Apologies for its length. As you can see, it’s saying that there are 0 issues, but in fact there are issues for that file, reported by SonarQube.
No worries, that’s not was I call “long logs”. You enabled “Verbose output”, that’s fine, but can you also tick “Analysis logs” in the SonarLint console, and then run the same analysis again?
Well… Now we can’t reproduce.
I suspect that the developer didn’t connect SonarLint to the SonarQube server and was running in standalone mode for some time. When I went in to help, I made sure he was connected, which might have fixed this. However, we have FindBugs and so he might have thought he was still not seeing issues, but now it was for a different reason: Because SonarLint doesn’t show FindBugs issues.
I’ll keep an eye on this with him and will let you know if anything changes.
I appreciate your help with this and now that I know more about how to look at the logs, that should help me too.
Your message has nothing to do with neither SonarLint nor the initial topic of this thread. Please do not bump old threads like this and open a dedicated thread for your request, with a bit more context than just a console dump.
