Branch Protection on multiple branches

[clphillips]

I’m wondering if there’s a way to apply branch protections in a regex kind of way. Here’s an example, I have multiple branches like release-1.0 , release-1.1  and I’d like them to all have the same branch protections. More importantly, when I create a new release-2.0 I’d like it to automatically be given branch protection with the same configuration as release-1.0  and release-1.1.

One way I’ve done this in other SCM management tools is by specifying a regular expression. Something to the effect of /^release-/

Is this possible?

[ThirdEyeRose]

Hi @clphillips,

Currently it is not possible to apply branch protections automatically in that way. However, we are looking to improve this feature over time, so I will pass on your feedback.

In the meantime, you can use the protected branches API endpoint to script some automatic branch protection based on the branch name.

Hope this helps!

[sfynx]

It looks like it has been introduced this weekend. I can now create a protection with wildcards for something like release/* and it will automatically show all branches it affects, presumably also all future ones. Long overdue feature as other repo management systems had this for a while longer already, I’m glad it is here now.

[OPeyrusse]

Hello Sfynx,

seeing this new feature, I tried the same approach as you. However despite having many release branches, the branch restriction page is saying that “Applies to 0 branches”.

Must I do something special to make it work ? As suggested I set the pattern to “release/*”.

Many thanks

[AndreaGriffiths11]

Hi @opeyrusse,

Branch protection rule patterns are based on fnmatch syntax. You could use releases/v?.? to automatically protect branches like releases/v1.0, releases/v2.0, and releases/v2.1. And [1-9]-[0-9]-stable could automatically protect branches like 1-0-stable, 2-0-stable, and 2-1-stable. To learn more about branch protection checkout configuring protected branches.

I hope this helps!

Best,

Andrea

[OPeyrusse]

Thanks @andreagriffiths11 for your answer.

It appears that / are treated specially. For me, the pattern releases* was not matching “releases/v1” but releases/* or any of your suggestions were working.

I also tested this on longer branch names, like “hotfix/client/project/1.7” and only the pattern hotfix/*/*/* was working. Removing intermediate “/” was breaking the pattern. It puzzled me as fnmatch documentation and its examples seem to imply that a standard hotfix/* or at least hotfix/** should have worked.

Thanks a lot for your help.

[ksraju-rms]

I am not able to use github api to add branch protection for a branch that does not exists or a branch with wildcard. 

Wanted to automate adding restrictions for all release branches (release/*) for all repos. Seems it does not work today and its a pain to add it manually as we have 100s of repos.

Ex: 

https://api.github.com/repos/:owner/:repo/branches/release/*/protection

Is there a way to do this automagically :slight_smile: ?? 

[nadiajoyce]

That’s not possible at this time. However, I will share your feedback with the appropriate teams. I can see how this would be valuable! 

[trusktr]

This would be great. Please!

I read in the another post that {master,develop} is not enabled in fnmatch. Can you provide another mechanism? Perhaps a UI with checkboxes as an alternative to pattern matching? That would be great!

[dominictobias]

Everyone talking about pattern matching and this is all I want, you'd think they would give this most common example even in a hint on the UI :/

[patrick-knight]

Repo rules has the native ability via the API and UI to include multiple patterns per ruleset

[jeffaburt]

+1 on adding support for this.

Looking more at the fnmatch documentation, it looks like there’s a File::FNM_EXTGLOB option that can be passed to enable{master,develop} to work. This option is disabled by default. Enabling it would save so much time for our organization when new feature branches are created that multiple people will work off of.

[Anahkiasen]

Would love this as well

[AndreaGriffiths11]

Hi @jeffaburt and @trusktr,

Thanks for being here, we actually  have an internal issue discussing this possibility and I’ve added your feedback to it.  Thanks again for reaching out! I’ll come back and post any updates here.

[tadms]

@andreagriffiths11 

Another +1 for getting this enabled.  

I am preparing a migration of 100+ repos to GitHub Enterprise.  The inability to automate (via REST API) branch protection rules for wildcard patterns (such as release/* and feature/*) is going to be major painpoint for us.  

[so-jelly]

@tadms  I think the wildcard patterns support is already available and documented here: https://help.github.com/en/articles/configuring-protected-branches

The request still pending here is for multiple name matches such as a regex OR.   I supposed you could be looking for this?  {release/*,feature/*}   Would this also be supported?

[tadms]

Yes, this is possible through the UI.  But I’m not looking to manually do this 100+ times through the UI. 

My request is to have this functionality with the REST API to be able to do this programmatically (originally requested by ksraju-rms in this thread).  

[Zutatensuppe]

Hello! @andreagriffiths11 :)

What is the current status of that feature? Where can it be discussed? It would be awesome to be able to use a pattern like {master,release/*,v[0-9]*}.

[AndreaGriffiths11]

Thanks for the ping @zutatensuppe, unfortunately I don’t have any updates for you “yet”

[fishercraigj]

I’d really like to be able to apply a single rule to the whole project as well no matter the branch name.

[FelipeCortez]

@fishercraigj  Doesn’t * work?

[fishercraigj]

Not for me.  

[joelpro2]

Reviving this thread
@AndreaGriffiths11 what's the status regarding to multiple root branches?
In my case, master and staging would have the exact same rules so i would expect something like {master,staging}

[behitesh]

@AndreaGriffiths11 any luck with this... thank you.

[mtmelvin]

It kills me that nearly 5 years in, we still can't easily apply the same set of rules to multiple branches like this. Wildcards don't work in this case since the names are completely different.

[tylerlaprade]

I am interested in this as well.

[ysma500]

Yeah, still bringing pain for a simple change: GitHub doesn't seem to pass the required File::FNM_EXTGLOB for this to actually work. Src. Stack Overflow

[EstebanMongui]

Based on @ysma500 comment, here is the rule to match develop and main at the same rule

[md][ae][iv]*[np]

Note: this rule will also apply for all branch's names which starts with 'm' or 'd' follows the sequence a-i, e-i, a-v or e-v and ends with 'n' or 'p'

[pohlt]

Fast-forward almost five(!) years and still no better solution than this [ab][cd][ef]* mess? Oh, please give us EXTGLOB. 🙏🏼

[Nauxscript]

there has been no progress in this issue for five years ... 🙃

[jonagh]

@AndreaGriffiths11 this discussion is set as answered, and I suppose it is as far as OP's question, however most of this discussion pertains to the fnmatch FNM_EXTGLOB feature being enabled so we can do something like "{branchone,branchtwo}". This seems like a very simple change and it has been years without action or indication. I'm concerned this issue is not being taken seriously because the discussion is marked as answered? or it's not being brought up with the relevant team? I don't know, but it's very bothersome to maintain a bunch of branch rules when one would do.

[patrick-knight]

Hey y'all,

Wanted to follow up on the discussion here, we recently introduced a beta of repository rules. One feature is it does allow for defining multiple branch or tag patterns per ruleset. It's still not RegEx or FNM_EXTGLOB but via the UI and APIs you can define multiple patterns for the same set of rules.

UI example:

API example:

  "conditions": {
    "ref_name": {
      "include": [
        "refs/heads/main",
        "refs/heads/master"
      ],
      "exclude": [
        "refs/heads/dev*"
      ]
    }

[patrick-knight]

Thanks to those who participated and shared solutions. As of the release of repository rules, this solution I posted above is the best way to manage this, as result we've unmarked the previous answer and updated the answer to reflect the best solution.