When we look at the pipeline history of the Orekit project on the develop branch, we see that some are successful and others stumble over the performance job.
The result depends on the ability of the committer to trigger the child pipeline on the evanward1/orekit-performance project.
Here are the permissions of the committers who have triggered the pipeline in the last few months, and the result of triggering the downstream pipeline:
All committers authorized to push code on the develop branch should be authorized to trigger the downstream pipeline.
As the evanward1/orekit-performance project is closely linked to Orekit, it should be published in Orekit’s namespace and not in a personal namespace.
Is there a security issue that justifies this? I can’t think of any, as the only privilege this downstream project has is the ability to push files to https://benchmark.orekit.org/orekit. The people to whom we could give this right are already authorized to push code into the Orekit repository, which seems to me to be far more critical.
Thanks for investigating this issue. There are no security reasons for this arrangement. The performance test code does need to be a separate maven module or project from the main Orekit code. I think moving it to the Orekit name space makes sense.
I originally put it in my personal name space while I was testing it. Then I left it there because it seemed to work from there. I didn’t realize it would create these permissions issues.
Thanks for being proactive in fixing these infrastructure issues!
I moved the orekit-performance project this morning to the orekit namespace, then adjusted the Orekit pipeline to point to this new path.
In order to manage access rights more efficiently and consistently, I’m creating two new groups:
Orekit Developers: people with write access to the official Orekit repository (i.e. committers)
Orekit Maintainers: people with the right to manage Orekit related projects.
I’m going to associate these two groups with the following Orekit projects in the Orekit group:
Orekit
Orekit Performance
Orekit Data
Orekit Tutorials
Orekit Website
The Orekit group will persist because it’s the group associated with the Orekit projects namespace, but with the two new groups created, it’s no longer necessary for most of you to belong to this group. So I’m going to remove them from this group.
These operations generate a large number of automatic e-mails. Don’t pay any attention for the moment, it’s just noise. When I’ve finished, I’ll let you know and ask you to check that you haven’t lost any access rights.
I’ve just finished configuring the groups and permissions. It’s a little bit strange, because the Gitlab interface doesn’t show the group members in the project members.
As a result, when you look at the list of project members, you get the impression that there are no developers or maintainers:
I therefore think that you have the required access rights and that there is no regression compared with the previous configuration. But please check it out and let me know if you encounter any issues.
Last adjustment, I’ve removed myself from repository owners, with the exception of the Orekit Website (I created this site) and ci-utils (I’m one of the two maintainers of this repository).
Talking about moving stuff in the official gitlab repo, shouldn’t we do the same with the branch used by @petrus.hyvonen to build the Python wrapper? I don’t know if that’s a bother for users or Petrus himself?
Having never looked at how the Python wrapper was generated, I have no opinion on the technical side.
On the other hand, from a governance point of view, there’s a small point to settle first: Petrus is a member of the PMC, but he’s not a committer (unless I’m mistaken, one doesn’t imply the other). He needs to be a committer to be able to autonomously maintain the branch on which the Python wrapper is generated.
I’m having a doubt, @serrof you were talking about the repository Orekit Python Wrapper currently in group “Orekit Labs” right ?
If so, it’s not a branch of Orekit but a different repo so @petrus.hyvonen can be the owner of that repo without being a committer on Orekit “official” Java repo.
That being said, I’d be glad that Petrus becomes an Orekit committer, it would be justified given all the great work he has done for the project so far !!
Actually I was talking more about the Java branch that he has to accommodate for the wrapper to be built. So that requires commit rights. But I’m also for the inclusion in the official project of the so called labs repo.
@MaximeJ drew my attention to the fact that, despite the changes I’d made to rights management, contributors who only had the “developer” role were still not allowed to trigger the “orekit-performance” downstream pipeline.
I suspect that the problem stems from the protection of the “master” branch in the “orekit-performance” project, which only project maintainers are authorized to modify or merge. I think this has a side effect on the ability of contributors to trigger the pipeline.
To be sure, I’ve just removed this protection. @Vincent, @Serrof and @markrutten, when the opportunity occurs, let me know if this modification is effective (not contributing to the code myself, I don’t spend my time watching CI/CD).
!