Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to turn off ability for administrator to merge pull request without getting approvals granted #17131

Open
my1e5 opened this issue Sep 23, 2021 · 9 comments · May be fixed by #32248
Open
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@my1e5
Copy link

my1e5 commented Sep 23, 2021

Feature Description

Say I am one of the 'owners' of a repo and I've set branch protection on the main branch. Specifically, I've set required approvals to 3.

This works fine for the most part, but on the pull request it shows 'As an administrator, you may still merge this pull request.':

image

So I could click the red 'Rebase and Merge' button and bypass the required approvals.

A feature I would really like would be a way to disable this ability. So that, even as an owner, I don't get this option to merge the PR without approvals.

Now I understand that, as owner of the repo, I have ultimate control of the settings. If I wanted to, I could go into settings and remove the need for required approvals. But that is quite an involved process which under normal circumstances I wouldn't do.

However, I want to avoid the temptation for an owner to quickly merge a PR without getting approvals granted first.

If I could just disable this merge button from showing, until approvals have been granted, then that would improve usability.

Screenshots

No response

@gtema
Copy link

gtema commented Jul 14, 2022

I have a different usecase falling on the same issue:

while implementing Zuul CI support for gitea I need to know whether PR can be merged. Now the "mergable" field is not really telling much forcing CI to go through all branch protection definitions and present reviews. But since that already requires having Admin privileges (/branch_protections/ api otherwise return 403) CI is capable to bypass requirements. This makes branch protections pretty much useless (CI need to reimplement all of them).

Instead either #13879 should be addressed, getting branch protections definitions should not require admin privileges or it should be possible to enforce them even for admin privileged account

@rudolphfroger-ds
Copy link

GitHub has a nice setting for this:

image

I'd also want the owner of a repo to adhere to the same rules, even if they can technically circumvent them by adjusting branch protection.

@Rainson12
Copy link

this is really anoying since its breaking our compliance as no one should be able to merge without approvals no matter whether he is owner of the organisation or owner of the repo.

@lunny lunny added type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Nov 23, 2022
@gempir
Copy link
Contributor

gempir commented Feb 3, 2023

Workaround:

Create a separate administrator account and remove yourself as an administrator.

@rudolphfroger
Copy link

I think the work-around is fairly useless if you have multiple owners in your organisation and then probably also one or more administrators per repository (to manage the repo settings). Then they all need to have two personal user accounts, one which is administrator and one which isn't. Each time you need to adjust some repository setting you need to switch accounts and not forget to switch back to the less privileged account.

@gempir
Copy link
Contributor

gempir commented Feb 9, 2023

Yeah I agree. That's why it's only a workaround. I would still like to see an option to either turn it off or hide the option more.

I recently setup a gitea instance for our team and added a few users as Admins and it got "abused" the next day skipping our CI and merging a tiny bit of bad code. Right now Admins are very powerful.

@AverageHelper
Copy link

+1

I don't want to be able to press the Big Scary Button by accident, even if there is a confirm dialog. (Is there such a dialog? I've never tried to use the Big Scary Button before as an admin.)

@frlan
Copy link

frlan commented Oct 11, 2024

Don't remove this option. It always needs an option to carefully cross the red traffic light in case of a e.g. a hotfix needs to be done _now. A am saturday morning in holiday season when all other devs are having beers for super bowl (or whatever scenario you like most)

@lunny
Copy link
Member

lunny commented Oct 11, 2024

GitHub has a nice setting for this:

image

I'd also want the owner of a repo to adhere to the same rules, even if they can technically circumvent them by adjusting branch protection.

This option is unavailable. Owner can turn it on, then merge and turn it off. Maybe a global option in app.ini will be better.

enko added a commit to enko/gitea that referenced this issue Oct 12, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 12, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
@enko enko linked a pull request Oct 12, 2024 that will close this issue
enko added a commit to enko/gitea that referenced this issue Oct 12, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 12, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 17, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 17, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 18, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
enko added a commit to enko/gitea that referenced this issue Oct 19, 2024
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes go-gitea#17131
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants