Troubleshooting
Knowing where to begin looking for information is the first step to reaching out for help. Many answers to commonly found problems can be found on the SonarLint channel of the Sonar Community Forum. See below for the basic steps to access the SonarLint logs when the analysis results are not what you expected.
Before posting to the Community, make sure that you have your logs ready by following the instructions below.
How to get SonarLint logs
- Open the SonarLint extension settings window: Manage (
) > Settings > Extensions > SonarLint - In the extension settings, enable the SonarLint > Output: Show Verbose Logs and select the SonarLint > Output: Show Analyzer Logs options.
- Then, switch the output in the VSCode console: Output > SonarLint
In addition, the VS Code Developer Tools Console can provide more information when troubleshooting.
- Go to Help > Toggle Developer Tools > Console in VSCode
- Clear your console.
- Reproduce the issue you encountered and check the output.
- A screenshot of your error may be helpful when posting to the SonarLint for VS Code Community.
Troubleshooting Connected Mode setup
No matching project found
No matching project is found because:
- It's best if you already have the project open in your IDE, otherwise SonarLint might not be able to find a matching file.
- SonarLint can get confused if you have more than one project open in different windows. Please close the non-applicable project and try again.
If these solutions don't help, follow these instructions to manually configure the project binding.
No matching issue found
SonarLint can't find your issue because:
- You might not be on the same branch.
- The issue was fixed, or the source code may be different from the analyzed version.
Troubleshooting unexpected analysis results
Sometimes, issues found on the server differ from those found locally by SonarLint. Usually, the server-side rule configuration (your quality profile) is to blame; however, it could be something more than that. Maybe your local build configuration and system dependencies don’t align with your DevOps pipeline, or it could simply be that the issue, due to its complexity, is only detectable by SonarQube or SonarCloud.
The collapsible below lists some of the most commonly encountered reasons, along with some details that will help you troubleshoot discrepancies.
Why your local analysis might be different than found on the server
Some issues might be detected by third-party analyzers
SonarLint will only run rules from SonarSource analyzers including custom rules extending SonarSource analyzers. Third-party analyzers usually have their own IDE integration, and there is no plan to run them inside of SonarLint.
Your test files might be mistaken as source files
Test files can be defined in SonarQube, on SonarCloud, or in the IDE. SonarLint for IntelliJ relies on the IDE to detect if a file is a test file, which is the case if:
- The file is under a test sources root. Those roots can be manually created by users or automatically populated by the IDE by relying on the build system such as Maven or Gradle, for example.
- The file is flagged as a test file by any plugin that you have installed. The IDE bundles some internal plugins like the “JavaScript and TypeScript” plugin; these internal plugins can infer if a file should be considered as a test file. Third-party plugins can also infer test files, and SonarLint will recognize these as such.
Some rules are too complex to run locally
Some rules can report issues at the project level or require extensive resources to analyze, such as tain vulnerabilities and some advanced bug detection rules; such issues are not displayed in SonarLint, only in SonarQube and SonarCloud. Please check the SonarLint roadmap for a list of features and enhancements on the horizon.
File or language types are not supported
Check your IDE’s Rules and languages page for a list of supported languages and file types.
The analyzer version may be different
Improvements are constantly being made to the Sonar analyzers during the CI/CD development cycle. Depending on the product version you are running, you may have a different analyzer therefore, the results might be different.
- SonarCloud is always running the latest analyzers.
- SonarQube runs the latest available analyzer at the time of its release.
- SonarLint runs the latest available analyzer at the time of its release.
- Sometimes SonarLint downloads and uses the same SonarQube or SonarCloud analyzer when running in Connected Mode.
Your project configuration may be different
Discrepancies in C and C++ analysis may result from different project builds and system dependencies. For example, you might have one set up in your local build configuration and another set up for your CI build configuration (or the configuration created by Autoscan).
FAQ
Are my SonarScanner properties applied to SonarLint?
No. Scanner properties you may have defined in the sonar-project.properties or pom.xml files (for example sonar.sources or sonar.projectBasedir) only make sense when using the SonarScanner in the command line. SonarLint tries to use IDE metadata to avoid other configurations.
If you want to share some configuration between SonarScanners and SonarLint, like File exclusions, or some specific analyzer properties, the best way is to use Connected Mode and set the configuration in the SonarQube or SonarCloud UI.
Was this page helpful?
© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.
