I’m about to migrate our SonarQube server from the old development platform to the new one. A question arises: should I take this opportunity to upgrade SonarQube from version 7.5 to version 9.9 LTS?
Generally speaking, it’s always a good idea to deploy a recent version of a tool and update it as needed, whether to benefit from new features or bug and security fixes.
But upgrading SonarQube is never easy, and always has consequences (or, more accurately, I can’t remember ever being able to change to a major version without losing the data history).
In the present case, problems are not probable, but certain! For two reasons in particular:
We’re using the Sonarqube Community Branch plugin, which runs counter to SonarSource’s business strategy. The company therefore makes no effort (to put it mildly) to take it into account in SonarQube version upgrades.
We use a community plugin that improves SonarQube’s integration with Gitlab. This integration did not exist in version 7.x of SonarQube, but SonarSource later decided to support it in the core of SonarQube itself, without worrying about compatibility with the community plug-ins.
Considering what I’ve just written, you might think that the decision is obvious: we have to keep the version we’re using!
This is indeed a possibility, but I see two problems ahead:
It will soon be 3 years since SonarSource stopped maintaining version 7.x LTS. Unmaintained code means uncorrected security flaws. In the long run, we risk paying dearly for this choice.
I don’t know how long an old version of SonarQube will be compatible with the latest versions of Orekit (remember, I don’t know anything about Java, it’s not my field, I just take care of the development platform and tools).
So my final question is: how important is it for you to preserve the history in SonarQube? Would you be willing to start from scratch?
Bonus question: do you see any other SonarQube issues to consider?
Feel free to express yourself, that’s why I’m starting this thread.
First, thank you for taking care of the CI and quality tools on Orekit!
I think we should upgrade yes.
I see two ways of keeping some data history for the next years:
Keep the old version online somewhere for reference but unplug it from the CI.
So we can have a reference of what happened on the older versions.
The new version would start with v12 and a fresh history
Remove the old version, start fresh, and build each version gradually from master branch, so we can rebuild a history. We could start from v10 for example or later (current SonarQube starts at 10.1).
But we would need to temporarily unplug deployment of the version to the Orekit Nexus repository otherwise it will “release” new artifacts with each build.
However, do we need that history? The only thing I’m interested in is the delta from one branch to another (from working branch to develop, from develop to master, and from new release to previous release).
There’s not much in the history that is useful to me, except maybe the overall measures (number of lines, global coverage, etc) for reference.
Since the Gitlab plugin is now an “official” plugin, the next upgrade should (hopefully) be easier. No?
I think we should upgrade. We already had some issues in the past due to too old plugins, I remember some odd issues with Hipparchus when GiHub flagged some maven plugins (for test coverage I think) as security risks but we could not change them due to SonarQube.
I also don’t think the history is worth preserving as far as SonarQube is concerned, we are more interested in preserving the source code history, and this is what git does for us. So just wipe everything if you want.
