Wildcard branches for branch deploys

I looked around for this, but couldn’t find any information on it. Does this already exist?

Our organization uses OneFlow, which essentially has four types of branches:

  • Release branches, which are prefixed with release/, e.g. release/v2.18.0
  • Hotfix branches, which are prefixed with hotfix/, e.g. hotfix/v2.18.1
  • Feature branches, which don’t have a prefix and can be named anything.
  • The production branch, which is named master.

For this flow, we’d like to have branch deploys (and especially Deploy Previews) running on any pull request targeting master, OR targeting a branch starting with release/ or hotfix/, but not on feature branches.

I can see that the Deploy Context settings allows me to add individual named branches, but it does not seem to support wildcards the way that GitHub does for branch protection, for example.

Is there any way to accomplish this with Netlify, or do I just have to build for all branches? And if there isn’t, would you consider adding support for wildcard branches?

Hiya @lemonsaurus and sorry to be slow to get back to you!

We do not have a wildcard branch feature right now; you’ve found the existing patterns:

  • specify a single branch
  • specify a pre-specified list of branches
  • specify all branches

We’ll only build PR’s which target your listed branches.

So, how can you more granularly adjust what we build? Without a built-in feature, some customers (us included) use zaiper.com as a “middle man”, in production, and have for years:

  • git sends all notifications to zapier.com. These notifications have a JSON body in a format that is reliably parse-able, and the payload includes things like the branch name!
  • at Zapier, you’ve configured logic to do that parsing, and implement your desired set of “buildable-at-netlify” commits.
  • you have Zapier “forward” (without changing!) the notifications for those commits, to Netlify.

This can be a bit finicky to configure for GitHub, since we don’t usually use webhooks to notify there, but if you aren’t turned off by the workflow let me know and I’ll talk through how you can get it setup. I can’t help with the code at zapier (ours is different than we’d recommend customers use), but that should hopefully be pretty straightforward - I am pretty sure Zapier “knows” GitHub commit notifications formats, and webhook “forwarding” is built in (cf https://zapier.com/apps/webhook/integrations/webhook/1676/send-new-caught-webhook-data-to-another-webhook).

We do also have an open feature request for making a real feature to do this, to which I have added your voice :slight_smile:.

Hi @fool, I really appreciate your response!

Using Zapier to accomplish this seems like a good and fairly straight forward idea. So far I’ve been chewing on the idea of just writing some sort of GitHub Action to achieve it, maybe even publishing it for others to use - although if you’re working on official support, spending time on publishing it loses some of its appeal.

Zapier would probably cost a lot less time to achieve, so it might be a good “quick and dirty” way forward for us.

I’d appreciate any examples or pointers you have easily available. I am very comfortable writing code so I probably don’t need a significant amount of handholding, but relevant example snippets and links would almost certainly cut down the completion time and are very much appreciated if you have them handy.

Hey there,

Unfortunately, I personally don’t have an example to hand so I’ll give the community to chime in!