Sonar-scanner support filtering of plugins

Got here via this thread - Sonar-scanner downloading unneeded plugins, but couldn’t see that a feature request had been created…so apologies if this is a duplicate.

We are in the process of trialling SonarQube and came across this issue as we started adding more and more plugins to support the different languages that our projects are written in.

Initially with just the golang plugin enabled, the project took ~1 minute to complete it’s analysis, but now with several other plugins enabled (css, js,PHP, python), the same stage take ~25minutes to complete…mostly due to downloading all of those plugins that sonar-scanner then doesn’t use.

We are using auto scaling ec2 gitlab runners, therefore each job is running in a clean environment with no cache, so having sonar-scanner only download the plugins for the languages configured with sonar.languages would be hugely beneficial.

SonarQube - Community Edition - 8.3.1
Using sonarsource/sonar-scanner-cli:latest doker image for the scanner

Hi,

Welcome to the community!

In fact, we added caching on the scanner side for just this issue - so that only the first analysis would take the download hit.

Also after a very long deprecation period, sonar.language (no ‘s’) has finally been completely disabled. It only ever set a single language and was necessary before the days of multi-language analysis but hasn’t been needed for a very long time.

I think your best bet is to figure out how to use the cacheing.

 
Ann

Hi,

Interesting to hear sonar.language has been deprecated/disable…didn’t see that anywhere in my learning…but makes sense given multi-language support.

My problem though is that gitlab runner instances are not persistent, and so the cache is clear for every new analysis.

I am playing with gitlab’s ci caching, but that only caches on a per project basis, so every new project would have this problem on the first run and/or if the cache is ever clobbered.

Being able to filter the plugins downloaded by sonar-scanner would mitigate some of these issues.

I also noted that sonar-scanner even downloads the prometheusexporter plugin, which I doubt it would ever need

The scanner was designed with the assumption that plugins can be locally cached. It needs to run them to dynamically figure out what files they will be interested in.
Redesigning it is not something that is in our plans right now, but might come at some point.

Gitlab’s caching should improve things a lot. Users usually have good results with CI caching since the files should be stored very close to the workers.