Wildcard Protected Branch #1075

New Issue

GiteaMirror · 2025-11-02T03:47:19-06:00

GiteaMirror commented

2025-11-02 03:47:19 -06:00

Originally created by @Andlix on GitHub (Sep 17, 2017).

Originally assigned to: @lafriks on GitHub.

With the last version, you could only protect branches that exists. But I think it should also be possible to protect branches given as wildcard (similar to GitLab),
e.g.
pu/*
release/*
*-stable
{user}/* (this branch should be protected except {user}

I think it would be a good idea to set these attitudes globally for an organization.

Originally created by @Andlix on GitHub (Sep 17, 2017). Originally assigned to: @lafriks on GitHub. With the last version, you could only protect branches that exists. But I think it should also be possible to protect branches given as wildcard (similar to GitLab), e.g. pu/* release/* \*-stable {user}/* (this branch should be protected except {user} I think it would be a good idea to set these attitudes globally for an organization.

GiteaMirror added the type/feature issue/confirmed labels 2025-11-02 03:47:19 -06:00

GiteaMirror closed this issue

2025-11-02 03:47:19 -06:00

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@stale[bot] commented on GitHub (Feb 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Feb 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@mbarinc commented on GitHub (Sep 16, 2019):

there are news about this feature?

@mbarinc commented on GitHub (Sep 16, 2019): there are news about this feature?

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@lafriks commented on GitHub (Sep 18, 2019):

I'm thinking to work on this for 1.11 version

@lafriks commented on GitHub (Sep 18, 2019): I'm thinking to work on this for 1.11 version

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@mbarinc commented on GitHub (Sep 23, 2019):

thank you @lafriks

@mbarinc commented on GitHub (Sep 23, 2019): thank you @lafriks

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@davidsvantesson commented on GitHub (Oct 21, 2019):

I think it would be a good idea to set these attitudes globally for an organization.

I think that should be a separate issue / pr to not make this too big. It need to consider some thing, like should it be a default branch setting that can be changed or deactivated in each repository?

With wildcard support it is possible that several settings match one branch, so the priority / combination of different branch protections need to be considered. Should only the first matching branch be used (means it must be possible to order them) or the most restrictive or the most permissive setting be used? What if there are different users/teams configured in different matching branch protection settings?

@davidsvantesson commented on GitHub (Oct 21, 2019): > I think it would be a good idea to set these attitudes globally for an organization. I think that should be a separate issue / pr to not make this too big. It need to consider some thing, like should it be a default branch setting that can be changed or deactivated in each repository? With wildcard support it is possible that several settings match one branch, so the priority / combination of different branch protections need to be considered. Should only the first matching branch be used (means it must be possible to order them) or the most restrictive or the most permissive setting be used? What if there are different users/teams configured in different matching branch protection settings?

GiteaMirror commented

2025-11-02 03:47:21 -06:00

@mbarinc commented on GitHub (Jan 3, 2020):

This is a very useful feature especially if it can be set at the organization level.
It's possible to put this issue in the next release 1.12?

@mbarinc commented on GitHub (Jan 3, 2020): This is a very useful feature especially if it can be set at the organization level. It's possible to put this issue in the next release 1.12?

GiteaMirror commented

2025-11-02 03:47:22 -06:00

@6543 commented on GitHub (Jan 3, 2020):

@mbarinc if someone has a PR for 1.12 or is working on it?

@6543 commented on GitHub (Jan 3, 2020): @mbarinc if someone has a PR for 1.12 or is working on it?

GiteaMirror commented

2025-11-02 03:47:22 -06:00

@lunny commented on GitHub (Jan 3, 2020):

@6543 I think no PR for this currently.

@lunny commented on GitHub (Jan 3, 2020): @6543 I think no PR for this currently.

GiteaMirror commented

2025-11-02 03:47:23 -06:00

@zerlas commented on GitHub (May 26, 2021):

@lafriks any news about this, it should be really cool to get this feature especially for organizations

@zerlas commented on GitHub (May 26, 2021): @lafriks any news about this, it should be really cool to get this feature especially for organizations

GiteaMirror commented

2025-11-02 03:47:25 -06:00

@zedar187 commented on GitHub (Mar 9, 2022):

I would like to bump this issue. Having a wildcard on * (as in "all branches", thus the complete repo) would be sufficient for the start, I guess. This way you can set general settings to the wildcard (thus on a repo level) and override the settings of single branches using the branch dropdown.

@zedar187 commented on GitHub (Mar 9, 2022): I would like to bump this issue. Having a wildcard on `*` (as in "all branches", thus the complete repo) would be sufficient for the start, I guess. This way you can set general settings to the wildcard (thus on a repo level) and override the settings of single branches using the branch dropdown.

GiteaMirror commented

2025-11-02 03:47:25 -06:00

@99rgosse commented on GitHub (Mar 15, 2022):

I will take a look at it, if I can help !
we are interested too :)

@99rgosse commented on GitHub (Mar 15, 2022): I will take a look at it, if I can help ! we are interested too :)

GiteaMirror commented

2025-11-02 03:47:25 -06:00

@frankhommers commented on GitHub (Mar 30, 2022):

I need this to. Especially for release/* ;-)

@frankhommers commented on GitHub (Mar 30, 2022): I need this to. Especially for `release/*` ;-)

GiteaMirror commented

2025-11-02 03:47:25 -06:00

@sIspravnikov commented on GitHub (May 5, 2022):

I'm interested too, it can be very usefull for repos with dozens of branches, that need to be protected

@sIspravnikov commented on GitHub (May 5, 2022): I'm interested too, it can be very usefull for repos with dozens of branches, that need to be protected

GiteaMirror commented

2025-11-02 03:47:26 -06:00

@99rgosse commented on GitHub (May 5, 2022):

Until I find some time on this, I made a workaround with a webhook and some api calls... it's quite fast and reliable !

@99rgosse commented on GitHub (May 5, 2022): Until I find some time on this, I made a workaround with a webhook and some api calls... it's quite fast and reliable !

GiteaMirror commented

2025-11-02 03:47:26 -06:00

@frankhommers commented on GitHub (Jun 29, 2022):

@99rgosse can you explain your setup. It's kind of dangerous without.

@frankhommers commented on GitHub (Jun 29, 2022): @99rgosse can you explain your setup. It's kind of dangerous without.

GiteaMirror commented

2025-11-02 03:47:26 -06:00

@99rgosse commented on GitHub (Jul 1, 2022):

Hello @frankhommers here is the repository : https://github.com/99rgosse/branch_protection
I'll try to keep this updated ;)

@99rgosse commented on GitHub (Jul 1, 2022): Hello @frankhommers here is the repository : https://github.com/99rgosse/branch_protection I'll try to keep this updated ;)

GiteaMirror referenced this issue

2025-11-02 11:54:03 -06:00

[PR #1097] [MERGED] Log config pretty printer to fix #1075 #15764

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1075