GitLab groups and subgroups... GitHub orgs and repos... who owns what?

The Eclipse Web Tools TLP's metadata shows that the project owns https://gitlab.eclipse.org/eclipse/webtools

The Eclipse Web Tools Releng metadata shows that the project owns https://gitlab.eclipse.org/eclipse/webtools/releng

My understanding of how privileges work in GitLab is that all of the Eclipse Web Tools committers have commit access the designated group and all subgroups, which means that anybody who is a committer on Eclipse Web Tools has committer level access on Web Tools Releng's repositories (regardless of whether or not they have committer status on Web Tools Releng).

Is my understanding correct?

In this specific example, our exposure is limited, so I'm not overly concerned about this specific example. I am concerned about the potential for similar scenarios.

I see something similar in case where projects share a GitHub organisation.

Eclipse Leda owns a GitHub organisation, https://github.com/eclipse-leda

Eclipse Leda Incubator owns four repositories in that same organisation.

That is, it appears that both projects effectively co-own all of the Eclipse Leda Incubator repositories, and that Eclipse Leda committers have commit privileges on all of those repositories.

Is this correct?

I am somewhat concerned that, if my understanding is correct, this does not conform with the EDP.

My more immediate concern is that from a metrics-gathering perspective, it's confusing to have repositories claimed by multiple projects.

Do any of our systems apply any logic to determine a single owner for a repository in these scenarios?

I'm thinking that we can use the ignored_repos field to manage this. The problem is that we have to actually manage this.

I've added the Eclipse Leda Incubator projects as ignored_repos in Eclipse Leda. I think that I can make that work.

But... if we're going to use one org for multiple projects, we're going to have to manage this.

The following repo from leda-incubator is not yet excluded for leda: https://github.com/eclipse-leda/leda-contrib-vehicle-update-manager.

The following repo from leda-incubator is not yet excluded for leda: https://github.com/eclipse-leda/leda-contrib-vehicle-update-manager

Good catch. I've added it. Thanks.

I looked a little harder. The reason why I didn't notice this at first is because the repository is archived. I skip archive repositories...

added IT-prioritylow IT-severitylow service:GitLab labels

changed the description

FWIW, the means by which I calculate the repositories that are "owned" by a project is this...

I query the project API. The value in the github_org field is sent to the GitHub API to get the list of repositories. We add the repositories listed in the github_repos field to this list. Then, we remove every repository that is inaccessible, archived, or is in github/ignored_repos from the list.

The list is further pruned to remove, for example, forks of JDK content from Adoptium projects (this is just hard-coded). These repositories don't provide interesting/useful metrics.

There is related discussion here: eclipsefdn/it/api/eclipsefdn-api-common#68 (moved)

marked this issue as related to eclipsefdn/it/api/eclipsefdn-api-common#68 (moved)

I've made some updates to the data and the my implementation which has resolved some of the issues. I've had to hard code a couple of things to make this work (hopefully that doesn't become too much of a maintenance burden later).

We will inevitably get back into a state where the ownership of a repository is ambiguous.

For the purposes of collecting project metrics, I've added an additional check/hack to mitigate against this that should have reasonably good results.

The query that gets the list of projects and their corresponding repositories favours the longest project id based on an assumption that the problem will most likely manifest in a scenario where the repository is claimed by a project and one of its subprojects (e.g., a project and its incubator that share
a GitHub org). When, for example, a repository is claimed by both automotive.leda and automotive.leda.ledaincubator, I assume that the repository is actually owned by the latter.

I do periodically scan for and resolve these sorts of anomalies.

marked this issue as related to #4593

marked this issue as related to #42 (closed)