SonarQube migration in progress

Orekit development
1

Dear all,

I’m going to start migrating the SonarQube instance from Orekit to the new infrastructure.

I’ll take this opportunity to upgrade from SonarQube 7.5 to 9.9 LTS.

This migration will cause the service to be temporarily unavailable and may cause Orekit and Hipparchus CI/CD pipelines to fail until I update the necessary information.

I apologize for the inconvenience,

Sébastien

2

Dear all,

I’m running into a problem with SonarQube 9.9 LTS. The Docker image used by Orekit’s CI/CD pipeline provides tools built with a version of Java (8) that is not compatible with the minimum version (11) required by SonarQube 9.9 LTS. As a result, the “verify” job fails with the following error:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.10.0.2594:sonar (default-cli) on project orekit: Execution default-cli of goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.10.0.2594:sonar failed: An API incompatibility was encountered while executing org.sonarsource.scanner.maven:sonar-maven-plugin:3.10.0.2594:sonar: java.lang.UnsupportedClassVersionError: org/sonar/batch/bootstrapper/EnvironmentInformation has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

A possible workaround is to use the Docker maven:3.9.6-eclipse-temurin-11 image. As its name suggests, it runs on Java version Temurin 11. Do you see this as a problem? This does not imply that the minimum Java version supported by Orekit must be 11. You can keep version 8 as your reference version. But the pipeline will use Java 11.

If that’s not acceptable to you, I’ll have no choice but to go back and redeploy a version 7.5 of SonarQube. :confused:

3

It is acceptable, but I hope that one day we will upgrade our Java version :slight_smile:

4

This is fine for me.

5

Fine for me too @sdinot

6

The new SonarQube server (9.9 LTS) is up and running.

But the migration has several side-effects:

  1. SonarQube evolution and the use of third-party plugins make any attempt to migrate data futile. I had to start from a blank database. Therefore, the projects and analysis reports that existed on the old version of SonarQube have disappeared. If you’re working on a repository other than the official Orekit repository, you’ll need to recreate your project in SonarQube. My apologies for the inconvenience. :confused:
  2. Nevertheless, I created the Orekit project and manually ran the same build process as the one executed by the CI/CD pipeline, in order to recreate the report history since version 11.0 (11.0, 11.1, 11.2, 11.3, 11.3.1, 11.3.2, 11.3.3, 12.0)
  3. @MaximeJ recreated the Quality Profiles and Quality Gates. Many thanks to him for this tedious task of reviewing and adjusting the rules. :pray:
  4. The good news is that SonarQube and Gitlab are now even more tightly integrated. This makes it easier to create projects in SonarQube.
  5. The bad news is that the alert thresholds have disappeared from Quality Gate. Only 2 states remain: success or failure. It’s all or nothing, glory or opprobrium! :wink: SonarQube justifies this by adopting the Clean as You Code approach.

I now need to adapt the CI/CD pipeline of the Hipparchus project to make its environment compatible with the new SonarQube instance.

2 Likes
7

Strictly speaking, it is not related to the SonarQube migration, but I made another modification: The SonarQube URL is no longer provided in the pom.xml file, but on the command line, through the SONAR_HOST_URL environment variable.

It’s not related to the SonarQube migration strictly speaking, but I’ve made another change on this occasion: the SonarQube URL is no longer provided in the pom.xml file, but on the command line, through the SONAR_HOST_URL environment variable. I will update the contribution guide to reflect this in the Configure SonarQube section.

8

Thank you Sébastien !!

I’m adding some information on the rules of the new Sonar instance compared to the old one.
This is valid for both Orekit and Hipparchus quality rules.
There is one rule that vanished between Sonar versions 7.5 and 9.9.4. I wasn’t able to find a similar rule with the new version. This is:

  • findbugs: IRA_INEFFICIENT_REPLACEALL
    Performance - Method uses replaceAll(String regex, String replacement) without any special regex characters

And we have four deprecated rules but I couldn’t find a newer equivalent for these neither:

Maxime

9

Thanks for all of this Sebastien and Maxime.

I don’t know if this is by design or not, but now it seems that there is no “new code” seen by Sonarqube at the first successful pipeline on temporary branches.

Cheers,
Romain.

10

Hi Romain,

You’re right, there’s no code considered “new” and it’s not “by (conscious) design” :slight_smile:

There may be an error in the configuration of what is to be considered new code. I’ll look into this and get back to you as soon as I have some idea of the problem (or the new way SonarQube works, you never really know with this tool).

11

The new code is evaluated against the previous version:

image

Here is the related documentation of SonarQube 9.9 LTS:

New code definitions

You can define new code as changes from a previous version, a specific analysis, a reference branch, or within a specific period (number of days):

  • Previous Version: Available at the global, project, and branch levels and works well for projects with regular versions or releases. Defines new code as any code that has changed code since the project’s most recent version. The current version of a project is determined in different ways depending on the build system being used:

    • If the analysis is done using the SonarScanner for Maven, then SonarQube reads the version from the pom.xml file.

The version currently specified in the pom.xml file is:

<version>12.1-SNAPSHOT</version>

I think the problem is transitory and comes from the fact that there is no previous version analyzed on the develop branch. Cf. this page:

image

In fact, I’ve rebuilt the history on the master branch, but not on the other branches.