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

1 Like

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.

I’m not in the exact same situation but I think being able to disable a plugin execution per project could address my issue.

I’m using an old version of Gradle (3.3) that only support Java 8.
I have installed SonarQube C++ Community plugin that requires Java 11.
Building the project using Java 8 will failed because, even if the project does not includes any C++ code, the C++ Community plugin will be executed leading to the error: The plugin [cxx] does not support Java 1.8.0_30.

So being able to disable the C++ Community plugin for this specific project can help me solve this issue.
Alternatives would be of course do the Gradle upgrade or downgrade the C++ Community plugin to version 1.3.3 that was compatible with Java 8.

Hi @amottier,

As a long-time SonarSourcer, it’s incumbent to point out that if you were to upgrade to Developer Edition($), which starts at only $150/year, you would have C++ analysis out of the box and be guaranteed* that that everything works together.

 
:smiley:
Ann

*To within the limits of human fallibility :wink:

Maybe times have changed by now.

We (and many teams in our company) run the sonarqube scanner as part of our CI workflow, which runs on managed gitlab runners. Our organization has a hosted SQ instance with a lot of plugins (because across the organizations, there are many different teams, who use different technologies). In our project we are only interested in javascript / typescript, so it would be great if we could avoid the unnecessary plugins.

Currently it takes ~10min to download the plugins per test run if the network is good, and if there’s a lot of traffic this can take up to 60min. For this reason we cannot / don’t want to run sonarqube before we merge. So we had to disable sonarqube, because it’s too slow.

Any chance that this can be improved, so that we can optionally specify the plugins which should be downloaded?

2 Likes

I encountered the same issue and would like to know how you managed to resolve it. I’m eagerly awaiting your response. Thank you in advance