We use SonarLint to analyze our code before we commit it. Unfortunately it only supports a small set of languages and GoLang is not on the short list.
To work around this limitation we’re trying to run the sonar scanner from the command line but unfortunately the report ends up empty with no code changes being reported, unless it has been committed. Forcing a local commit of all changes will lead to inconsistencies and confusion for our developers.
The much preferred solution would be to update sonar-lint to support GoLang, but in the meantime we want Sonar to be a positive experience for our developers.
When you that the report ends up empty, are you talking about PR analysis? I think so, because otherwise uncommitted files should be included in the report. Please do clarify.
Also, I’m wondering if using -Dsonar.scm.disabled=true might be a suitable workaround for your use case. Have you tried that?
We are trying to allow developers to run an analysis before they push for a PR, so before PR analysis. We want to do this as a workaround for SonarLint not supporting GoLang. We would much much prefer to use SonarLint but the GoLang support seems unlikely to be implemented in the short or medium term.
We tried the -Dsonar.scm.disabled=true option but in that case all the code that is different in master get flagged and if the user has not pulled from master very recently they see a report on all the files that are different from master, not just their pending changes, which in practice is even less usable since they have to filter out a lot of noise.
I’m afraid that at least for the time being, the best available workaround is to stay rebased on master and use the -Dsonar.scm.disabled=true option.
For the record, when using Git, the scanner looks at the difference between the fork point with the base branch, and the HEAD. This behavior supports well the typical use case, where the scanner runs in a CI system, triggered automatically, and uncommitted changes are neither expected nor desirable to include in the analysis.
I can imagine an option to modify the default behavior to support your use case. However, keep in mind that this is the first time I hear such use case, and we’re talking about a hacky solution for a poor workaround… Nonetheless, I signal this to our product managers, but don’t hold your breath!
Thanks for reporting, it’s good to know that there’s interest for the inclusion of GoLang in SonarLint.