Custom repository roles are not granular enough for some use cases #12703
Unanswered
manneorama
asked this question in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
As an internet bank, and I'm sure many other fields have the same burden, we live under certain rules and regulations. One of these rules is the 4-eyes principle, i.e nothing can ever be merged without an approved PR. Hence, we can't let teams modify the branch protection rules of their repo because then they could disable protection and thereby circumvent regulation.
A lot can be argued about trusting people to do the right thing of course, but unfortunately government agencies that audit the adherence to these rules and regulations aren't really interested in those arguments but rather they operate on the "can you or can you not circumvent this rule"-level.
We had high hopes for the Custom repository roles feature as it would remove a ton of admin work and maintenance around tooling related to this, as we hoped that we would simply be able to say "Allow all the things except modifying branch protection". But as it stands right now, allowing all things except the "Push commits to protected branches" checkbox when creating one of these roles removes a lot of other things that we do want our developers to be able to do. Such as delete, rename or archive a repo, or have full control over PR settings.
We hope that we're not alone in this use case, and that this can spark a discussion around the granularity of the repository roles. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions