Visibility of orekit-performance project

Dear all,

In GitLab, access to the Orekit project is public: anyone can see the project, its source repository, its issues, its CI/CD pipelines, without having an account on the forge.

Orekit’s CI/CD pipeline triggers another, which appears as the final step in Orekit’s pipeline.

This is the orekit-performance project pipeline, whose visibility is not public, but internal. In other words, access to this project is restricted to people identified on the forge. To access it, you need an account on the forge. Once logged in, you have automatic access to this project.

I don’t understand this configuration. Either the project contains no sensitive information and can be made public, or it does and access must be even more restricted, limited to project members only (the legitimate members being Orekit developers).

@evan.ward, as you are the author of this project, can you tell us what you think of it?

Have a nice day,

Sébastien

1 Like

Hi,

I’m upping the thread. More often that not, after a commit on Orekit, the pipeline fails in this project and I find myself restarting it once or twice. It’d be good to know why I guess.
And I agree with you Sebastien, we should clarify the goal and contributions.

Cheers,
Romain.

1 Like

I think that was just me not understanding GitLab permissions. The goal is just to run some jmh tests and try to recreate the view of the Jenkins JMH plugin in GitLab CI. So we as developers can see how changes to the code impact performance.

Everything I’ve pushed to that project is public. (I just assume anything I push to Orekit’s GitLab is public.)

Regards,
Evan

2 Likes

The orekit-performance project can therefore be made public. I’ve just changed its visibility.

I took the opportunity to change the apparent name of the project:

orekit-performance → Orekit Performance Tests (as in the README file)

The slug remains unchanged.