the problem that the Sonarqube-Scanner simply downloads ALL plugins from Sonarqube, has improved crucially - thanks for the " Analyzers loading optimization"
But there’s still a problem with the large filesize of some plugins, especially the
sonar-javascript-plugin-10.13.2.25981-multi.jar with a size of nearly 80mb in restrictive environments.
The size is explained by the included nodejs runtimes for Linux and Windows, i.e.
While it seems a proper approach for convenience it causes problems.
We have a central Sonarqube instance that is accessed from different network zones, means proxies … etc. involved. There are timeouts of 5 min that can’t be increased.
I can’t think of ANY serious CI/CD system, that hasn’t configured it’s own nodejs / Java … runtimes.
So either go back to the old days - where a nodejs runtime was required - or a server property that controls whether a sonar javascript plugin with included nodejs runtimes is really needed or a smaller sonar javascript plugin without bundled runtimes is sufficient.
Of course you then have also to ship a smaller sonar javascript plugin.
But IMO your approach is wrong. Every npm build needs a nodejs runtime, right ?
If a CI/CD system drives frontend builds (including the Sonarqube analysis), it needs - and already has - a configured nodejs runtime environment.
Will you also start shipping a JRE and dll for mssql integrated authentication in the future !?
BTW that’s often wrong in the docs after releasing a new Sonarqube version
just one example
Shipping a bundled nodejs runtime is well-intentioned, but overkill / causes problems.
How to implement “downloading only the target platform architecture”, guess you have to ship different editions of the sonar-javascript-plugin ?
Then you might also provide a variant without a bundled nodejs runtime.
The timeout of 5min comes from load balancers, this causes failed builds because of socket timeouts after a Sonarqube update when scanners have to download the new plugins.
Right now yes. No other tool transfers such big files.
What kind of bandwidth are we talking about? Are you using custom plugins that are adding to the overall payload? Is this happening on a JS/TS-only project, a mono repo, or something else?
Given the selective download, I wonder if scanning a single JS file project would pass or fail too with this kind of constraints.
Coming back to your suggestions, we have a version of the plugin that does not embed the runtime.
In theory, one could download it from the Maven repo and pre-populate the cache, or one could modify the SonarQube installation to replace the artifact.
Of course, this would be a big hack. I can’t make any guarantees since we don’t test or support this officially. It would likely break with upgrades or might not work at all.
