We have generated mock files to test our Go code and we have been using the
sonar.go.exclusions key to exclude them in our sonar-project.properties file. This used to work as reported in this thread: Sonar.go.exclusions top level directory matching issue
Our properties file has:
sonar.exclusions = \
# GoLang Settings:
sonar.go.exclusions = \
Yet we are seeing a lot of issues flagged on our
*_mock.go files. Since these are files automatically generated by
mockery we need them to be excluded from analysis. We do know that
sonar.go.exclusions used to work, but it does not seem to be honored anymore.
The Admin UI does show
sonar.go.exclusions as an option for Go so this seems to be a recent regression.
I could reproduce this using a sample repo like GitHub - xosmig/roguelike: Rogue-like game written in Go using Termbox-Go library
Thanks for the report. I’ll flag this for attention.
Thanks @Colin. If it helps I checked our historical metrics and our lines count increased on October 5, and went back down after we added the
sonar.go.exclusions content into
There was probably a new release of the golang plugin on that day that introduced the regression.
Thank you @sodul for documenting the problem, and thank you @Colin for confirming the issue.
I am trying to pin down the version where the behavior has changed. Can you tell me if you are running against SonarCloud or SonarQube? And if SonarQube, which version?
@Dorian_Burihabwa this is with SonarCloud on a private project.
So… it’s weirder than I thought.
I have set up this dummy project and analyzed both on SonarCloud and on a local SonarQube instance (with the same version of the analyzer).
On SonarQube, the filtering is correctly picked up but not on SonarCloud both by configuring the project on SonarCloud and setting values in `sonar-project.properties.
So my guess is that the filtering logic has changed recently on SonarCloud.
I think it is best to send the topic to the SonarCloud experts.
Hi @sodul ,
Thank you for making us aware of this issue, we believe we may for identified the cause of this issue and are investigating a possible solution. We will update you here once this has been deployed, I hope this would then resolve the issues that you are experiencing.
It has been suggested that for now if you enable
sonar.plugins.loadAll=true when running the analysis, this should allow you to process whilst the issue is being resolved.
Our current workaround is to add the content of
sonar.exclusions and the PRs are working as intended.
Is this change related to the idea that not all plugins will get downloaded anymore? Do you have documentation about
We actually have a separate pipeline to ‘cache’ the plugins. We use ephemeral containers that run on kubernetes which means we do not have persistent volumes with local caches and so have a separate pipeline that caches the sonar providers. I took a look at that pipeline and still see
sonar_cache.tgz 137.69 MB so it looks like all the providers are still being downloaded and cached.
I’m glad that you currently have a workaround, it sounds like a good idea for now, I imagine that it will also be a bit faster than using the sonar. plugins.loadAll option so I would continue with your current setup for now.
Yes, this is related to the optimization process, we believe that there is a timing-related issue where the plugin is being loaded only after the project files have been indexed. This is what is currently being investigated.
I’m afraid I don’t have any specific documentation available for this, I will update if I am able to find something useful for you.
A fix for this issue has been deployed. It sounds like you have a workaround in place, but if you decide to revert to your previous configuration, please let us know if the issue persists.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.