New continuous integration platform proposal for Hipparchus

Hipparchus development
1

Dear all,

As you probably know, we recently migrated the Orekit continuous integration platform to Gitlab CI/CD, SonarQube and Nexus. Indeed, we want to eventually get rid of Jenkins, with whom we are not satisfied for several reasons. As the Hipparchus source code is hosted on Github, the continuous integration can not rely on Gitlab CI/CD (this would only be possible with Gitlab Enterprise Edition). So we had to consider another platform, modern and well integrated to Github. Fortunately, the Github platform was enriched a few months ago with a continuous integration tool: Github Actions.

To evaluate the potential of this service and to verify that it was possible to do what I wanted to propose to you, I used it on my Hipparchus fork.

Here is an example of Github Actions workflow execution:

https://github.com/sdinot/hipparchus/runs/500392809?check_suite_focus=true

The CI workflow is defined in the .github/workflows/maven.yml file (on the develop branch).

I used SonarQube to replace the Jenkins dashboard and provide you with a better code quality monitoring:

https://sonar.orekit.org/dashboard?id=org.hipparchus%3Ahipparchus-aggregator

I have tried to reproduce in SonarQube the existing Checkstyle and SpotBugs rules and exceptions, but there are certainly some adjustments to be made.

I then added the publication of the artifacts in Orekit’s Nexus repository:

https://packages.orekit.org/#browse/browse

The artifacts corresponding to Hipparchus official versions will be published in the “maven-releases” repository. Those corresponding to the development branch (snapshots) are published in the “maven-snapshots” repository.

Would you be willing to migrate the Hipparchus continuous integration platform to Github Actions, SonarQube and Nexus OSS? Would you have anything to change in this platform and its current configuration? Would you prefer another solution?

All comments and questions are welcome.

2

Thank you @sdinot!

I have a question about the multi-module aspect on SonarQube. Is it possible to disable the CI platform and SonarQube metrics on a specific module of the project?

For example, it seems to me that the hipparchus-samples module is only there to provide examples of use. In this case, this module could be excluded from the CI platform and SonarQube radars.

Now, from a Hipparchus user point of view, I find the use of SonarQube very interesting.

Bryan

3

I thought I did:

image
image787Ă—250 11.6 KB

But, obviously, it is not the case. The syntax I used is probably wrong.

4

Great!

Big +1 to use a modern Continuous Integration.
The SonarQube interface is much more comfortable than the old Jenkins one and I was never able to find anything in the new one (BlueOcean?).

I think that with this new tool, we could also probably tighten progressively our checks; our checkstyle rules for Hipparchus are pretty limited and I fear some bugs may slip through.

5

I like the idea of moving to these more standard (for today) systems but I haven’t personally implemented any of these things before so can’t speak to the difficulties associated with it.

6

As you moved QA rules to Sonar, it will be certainly useful to add SonarLint to your IDE. With such tooling, you will be able to check QA directly in your workspace, without waiting for a push+feedback loop, and inside the effective source files you can edit.

1 Like
7

I understood my mistake. As Hipparchus is a multi-module project, the paths listed in the sonar.exclusions parameter are relative to the module directory, and not to the base directory. Therefore, the directory hippachus-samples must not appear in the path:

image
image780Ă—186 6.16 KB

As I know nothing about Java, I have difficulty evaluating the possible consequences of this setting. I hope that the path “src/main/java/org/hipparchus/samples” will never appear elsewhere in the repository.

Here is the result in SonarQube.

8

An other solution could be to skip the sonar mojo in sample project.

All maven plugin generally support the skip parameter and a related property.

I think you can simply add in sample project:

<properties>
...
<sonar.skip>true</sonar.skip>
...
</properties>
1 Like
9

Thanks for the tip. Applied!

10

OK, I think we should really go for it.

11

@luc has agreed my merge request. Hipparchus continuous integration relies now on Github Actions:

https://github.com/Hipparchus-Math/hipparchus/actions

And a better quality report is now provided by SonarQube:

https://sonar.orekit.org/dashboard?id=org.hipparchus%3Ahipparchus-aggregator

A few adjustments remain to be made, but the most important is done. Now, we are in a position to abandon Jenkins in the near future.

1 Like
12

:clap: :clap:
Thank you SĂ©bastien !!