Hi,
we’re running some special Jenkins builds for Android in Docker containers that are destroyed afterwards.
This means every new build downloads all available scanner plugins from our Enterprise instance again, but in fact we would only need the Kotlin scanner beside the core plugins.
Would be fine, if we could restrict the amount of downloaded plugins to only those that are really needed.
Or is there already a solution for that !?
Gilbert
Hey Gilbert.
We recently did a POC of this internally and… landed in a worse state than before. Though it sounds like a trivial problem to solve, it’s actually quite complex.
For the scanner to decide what analyzers to download, it needs to get the information about the languages supported by each analyzer and each languages file suffixes before downloading the plugins…
Instead, we’re focusing our speed of analysis efforts on improving the time it takes for SCM data to load on first analysis, incremental analysis (only analyzing changed files) and additional caching mechanisms (going language by language). There’s a lot in store for the v9.x series!
However, coming back to your case, you might try to cache the /.sonar/ folder so that it persists between runs and not all plugins have to be downloaded. I don’t have any specific recommendations to share for Jenkins + Docker.
Hi Colin,
Yes, the scanner must know the relevant language(s) before. Thought that might be possible
via a new scanner property which is send to the Sonarqube server before.
In this case we know it’s only Kotlin.
There are different network areas involved.
We have one central Sonarqube instance in LAN, but this Jenkins build runs in another network area.
This means every binary that is transferred from LAN to other network areas is scanned by proxies and gateways, which costs valuable time and electricity - think of timeouts, restart the build …
Gilbert
Hi @Colin ,
is this being pursued / still under consideration or is it on hold ?
Otherwise we will try to cache the /.sonar/ folder
Gilbert
Hi Gilbert,
We’re still working on speed of analysis, but the current focus is analysis cacheing (so that we don’t re-run a full analysis on unchanged files). We’re not working at all on limiting the downloads from the server. So cacheing /.sonar is probably the way to go in your situation.
Ann
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.