The future of sonar-golang

[danielleberre]

SonarSource is going to provide its own open source sonarqube plugin for the go language called SonarGo next month.

This is a good news in our opinion since now go will be a language officially supported by SonarQube.

The approach taken by SonarGo seems different from our plugin: instead of retrieving the issues/data from external tools as we do, they are analyzing with their own rules the files.

The advantage is to be able to support the same set of rules across all languages.

The disadvantage may be to loose some rules you are used to with current go linters.

In the long term, it also means a tighter integration with SonarQube.

As such, the future of this plugin is not clear once SonarSource plugin will be available.

If there is no need for this plugin anymore, we are happy to move to SonarGo.

Some people may however prefer to rely on current linters, thus continue to use this plugin. In that case we would be happy to continue maintaining it.

Please feel free to comment in this issue to tell us if you think there is still a need for this plugin.

Update: the plugin has been released by SonarSource
https://www.sonarsource.com/resources/product-news/news.html#sonargo-1.0

[rkettelerij]

I'm currently happily using this plugin (kudos for creating this!). I'm also glad to see SonarSource providing official language support. Would it be an idea to rename this plugin to sonar-go-metalinter? Since that's what we're currently using it for, as a SonarQube wrapper around GoMetaLinter.

[danielleberre]

Yes, that's an option.

The idea would be to remove all code related to testing and to focus on the go metalinter integration with SonarQube.

There would be some changes also needed in the code to make it compatible with the current SonarGo.

[mohanraj-r]

• Does the sonargo plugin have a way of customizing and disabling checks as necessary with a config file? We currently use a config file in our repos which controls the checks performed by gometalinter.

• Another advantage of gometalinter would be that we can run it locally in our dev env before checking the src in. Guess this is not a possibility with the sonargo checks.

[rkettelerij]

Since SonarGo 1.1 it's also possible to import GoMetaLinter reports in SonarQube. So this basically mimics the behaviour of this plugin, plus the additional features found in SonarGo itself.

So I think its safe to say SonarGo can fully replace this plugin at this point (for me). Again thanks to the maintainers (@danielleberre et al) for creating and maintaining this plugin!