SonarSource is pleased to announce the release of 7.2 today.
I’m not going to go into the features here because we’ve spent some time crafting a new announcement format: SonarQube 7.2 | SonarQube
What I am going to list here are the technical details that aren’t included in that new announcement:
There are four different packages now: 1 for each edition. That means that upgrading gets a lot simpler if you’re on a commercial edition: just download the right one and you’re ready to go!
All bundled plugins are in the plugins directory by default. So don’t just blindly copy over all the plugins from your old installation, or you’ll end up with multiple copies of your analyzers and startup will fail.
There’s no Docker image (on purpose, we didn’t forget!) for this version.
For faster future upgrades, we’ve added documentation on how to configure your Elasticsearch storage paths to reside outside $SONARQUBE_HOME. Starting from 7.2 we’ll only drop and rebuild the ES data when it’s really necessary (versus always, as with previous versions).
It’s a long story. The gist is that the docker images for previous releases were only semi-official (hosted under our aegis, but not really supported by us), and the change to 4 distributions brought us to a bit of a crisis point on this topic.
We’ll (probably) get “soon” to where we distribute and officially support an image for each edition, but we’re just not ready yet and we didn’t want to put out an image for only one of four distributions.
I really like this new feature to import issues found by 3rd-party analyzers. This is a great step into the right direction! I’m only wondering why there are these two limitations?
They cannot be managed within SonarQube; for instance, there is no ability to mark them False Positive.
The activation of the rules that raise these issues cannot be managed within SonarQube. In fact, external rules are not visible in the Rules page or reflected in any Quality Profile.
Is this only an intermediate step or already the final version?
What’s the reason behind this limitations?
The reasoning behind these limitations is that we’re not managing the rules, so we shouldn’t manage the issues. Specifically, you configure the linter entirely outside of SonarQube, and run it outside of analysis, so if you want to stop seeing certain issues from it, you should handle that in your external configuration.