Offer more control over Github repositories to committers

Currently, committers only have write role on the their projects' Github repositories and project leads have maintainer role.

Maintainers can only configure a limited set of things on the github repositories. For example, managing branch protection rules or configuring tag protection rules are not possible without admin permission. We'd rather not grant admin permission as we would like to keep a tight control over user permissions to ensure compliance with the ECA.

We would like to offer a solution to let projects' committers and PL do more without having to open a help desk ticket every single time.

/cc @gadamsuwr who already has a PoC for this.

added Infra prioritylow ~16280 severitynormal team:security team:webdev labels

mentioned in issue #1524 (closed)

I think this is a great idea! We will need a way to set our default settings for all orgs/repos and allow each project to propose a PR if they wish to alter a setting.

In order to stay organized, I am thinking we could have 1 config file per organization but that's just an idea.

As discussed yesterday with Mika, this functionality does not need to be included in our sync script since we only need to run this script when we merge a PR from a project that wishes to change a setting.

Additional context from #1524 (closed): the suggested solution involves a infrastructure-as-code script that sets certain options.

@mbarbero has there been any update here? As mentioned before I'd be happy to collaborate on a solution

@gadamsuwr can you share a link to your PoC?

marked this issue as related to #1620 (closed)

mentioned in issue #1620 (closed)

This looks interesting solution, especially to those that are used to having full control over the repository (like raised in #1620 (closed)). Has any request been made to GitHub for further granularity on permissions so that items affecting EDP (like committer list) can have tight control while other items are more accessible (like descriptions/icons/etc)?

@fgurr take a look at https://github.com/gdams/repo_manager (I quickly dumped my work into a repo so it's still very much a WIP)

FYI, I've just been made aware that there is a terraform provider for github that does that (and much more) https://registry.terraform.io/providers/integrations/github/latest/docs

@mbarbero any update on this?

Actually, yes. We've started a prototype, taking your work as inspiration. That's very much WIP as well, but to meet our requirements, we had to change the base tooling. It's now based on the gh CLI tool for REST and GraphQL API calls (as some stuff are only accessible via GraphQL) and also some Puppeteer scripts for things that are only available from the UI.

It's still private for now but should be made public by the end of the month.

Here is the link: https://gitlab.eclipse.org/eclipsefdn/security/otterdog

Great! how can we start using it

We will try to set this up in Q1, but we can't promise anything. We're pretty swamped with support work.

Hi @fgurr / @mbarbero is there any chance of us getting Otterdog running on our org this quarter?

Fred's previous status still applies, unfortunately.

@gadamsuwr, work has resumed on that front and you will see updates soon. I don't want to be too optimistic about production deployment this quarter, but should ok in Q2.

mentioned in issue #536 (closed)

I think that can be closed by now as otterdog is now in productive use (while still being updated ofc).

Indeed.

closed

@netomi @mbarbero Hi, correct me if I'm wrong - self-service using otterdog is not possible for repositories in https://github.com/eclipse, only possible for other GitHub orgs?

Technically it would be possible to also manage the eclipse organization with the self-service but we would like to have every project in its own GitHub organization for different reasons. So if you would like to enable self-service for your project, first migrate to its own GitHub organization.

@netomi Got it. Thank you!

mentioned in issue #4074 (closed)