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

Allow to specify to not require approval for everyone with write access to repo #4791

Closed
lafriks opened this issue Jan 30, 2025 · 5 comments
Closed

Comments

@lafriks
Copy link
Contributor

lafriks commented Jan 30, 2025

Could we also have option to specify, that users that has write access to repo should not require approval? Just an idea and probably not part of this PR

Originally posted by @lafriks in #4768 (comment)

@qwerty287
Copy link
Contributor

Tbh I'm not sure if I would rather keep that feature small to keep our code simpler. As we said multiple times already, we can't just always add new features as we can't even handle all bugs for the current ones.

Anyways, I'd close this in favour of #2293

@anbraten
Copy link
Member

anbraten commented Feb 1, 2025

Actually I think the list of users being allowed to approve is actually a feature that we could replace with this kind of automatic list of repo maintainers.

@qwerty287
Copy link
Contributor

I don't think so, as you might have bots that do pull requests from a fork (e.g. weblate on codeberg).

@xoxys
Copy link
Member

xoxys commented Feb 4, 2025

I'm sorry if this is annoying, but I still don't understand why we don't want to allow admins to write their own policies. This could be done through a validation extension system (https://docs.drone.io/extensions/validation/) or through some kind of policy engine, be it an existing one or a small custom implementation.

Every time I bring this topic up, there is no real feedback, but we very often discuss extending the gated repo feature with new cases. While I agree that the core functionality of gated repos should be kept as small as possible, I think that simple extensibility would solve most requests for such functionality.

@qwerty287
Copy link
Contributor

I personally would even say we could limit the feature to how it currently is, but I can also imagine different usecases. But I agree to @xoxys to not add this to our core, rather using something like #783 #3349

Anyways, as I said already, this is actually a duplicate of #2293 and I'll close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants