Automatically deploy branches that match name pattern

@futuregerald,

Awesome, I should be able to find a sufficient workaround between the two!
Just knowing there’s a reasonable path forward is exciting.

Thanks for the help!

1 Like

I would find this feature useful as well.

We frequently create feature branches and merge them to master but don’t always want to release these features immediately. We control the release cadence by branching from master with release/* branches and these are what get published (e.g. release/v1.2)

We would like to have a similar setup with Netlify where only release/* branches get published to production. But have the integration with GitHub feature where you can preview what the site looks like with any feature branch, etc.

Sounds like the workaround for now is to manually add the release/* branches to Netlify. But what I’m not sure about is if you can do this without a subdomain:

If we have ourwebsite.com as the main domain, can we have release/* branches deploy to ourwebsite.com? Or would it end up something like release-v1-2.ourwebsite.com?

1 Like

Thanks, added your name to the feature request around wildcard matches in branch name specification!

re: publishing more than one branch to production, no, we wouldn’t intend to enable that workflow directly. You could certainly do something like send your notifications for successful builds to a service like zapier, and based on the branch name (zapier CAN parse the branch name to look for patterns like the one you want), selectively use our API to publish, in case your conditions are met:

You could also use the API to update the site’s production branch name (see this article for details on how to discover the API calls needed for any operation our UI can do:


), and then we’d auto-publish based on the new branch being the production one before we receive a commit notification

1 Like

That feature would be useful for me as well.

My use case is somehow different. Due to the lack of an ability to remove preview branch (e.g. some work-in-progress version to show someone) I have another “disposable” site for that repo (to be able to delete the whole site if needed) and I would like to publish there only pages from branches disposable/*. Now I have to specify manually disposable/preview1, disposable/preview2 and/or reuse branches.

1 Like

Thanks, I’ve added your vote to the feature req :muscle:

1 Like

Hi! I was wondering if any progress has been made on branch pattern matching features? I’d like to leverage what’s described here.

Thanks! :slight_smile:

1 Like

Hi, @afontcu. We have added your vote to the feature request. We will post an update here as well if/when this becomes possible.

1 Like

+1 vote, just to track this issue

1 Like

noted, @slorber! we’ve added your voice to this feat request.

+1 on this. We could really use support for wild card and/or ! for deploy branches. (generally regex support)

1 Like

Thanks, @TerryDC- added!

+1 on this too, it’d be really useful for our workflow

1 Like

Understood & added, @ahtcx!

1 Like

+1 on this general idea of pattern matching in deploy contexts, it would be a great feature. In our case we use Netlify CMS for our Comms team to make content updates. These don’t really need tests to be run so we would rather just do the static build and have the deploy preview ready quickly. These PR’s from the CMS always follow a similar pattern cms/*. When the engineers make PR’s then we want our test suite to run as well. Pattern matching would make this a lot easier rather than having to introduce a slightly fiddly workflow.

1 Like

Makes sense, @knoxjeffrey and thanks for sounding off!

We may or may not ever implement this directly, but your can already self-serve on this today, using the build.ignore script to select which branches to build - it’s a shell script that runs with your repo, and our environment variables (such as $BRANCH and $CONTEXT present, and you have access to run commands like git status to understand what branch a commit is on and react conditionally to it. I haven’t tested this, but hopefully it demonstrates what I mean:

if `echo $BRANCH | grep cms` ;
  then return 1
else if ["$CONTEXT" == "production" ] ;
  then return 1
else
  return 0
fi
1 Like

Hi @fool, sorry for the late reply I’ve been away on holiday and just spent the last day experimenting with the setup. That’s really cool that you can do that in the netlify.toml file. I’ve now got my setup for Middleman working like this:

[context.deploy-preview]
  command = '''
  if echo $BRANCH | grep "^cms" ;
    then NO_CONTRACTS=true RUBYOPT=-W0 middleman build $CMS_PR_BUILD_OPTIONS
  else
    yarn test && RUBYOPT=-W0 parallel_rspec -n 2 spec && NO_CONTRACTS=true RUBYOPT=-W0 middleman build --verbose
  fi
  '''

[[plugins]]
  package = "netlify-plugin-chromium"

So on a deploy preview, if the branch begins with cms then I can run just the Middleman build command, otherwise it’s running all of the specs first and then the build. I’ve also got CMS_PR_BUILD_OPTIONS empty by default but if a build from the CMS fails then I can quickly add --verbose to the environment variables in the Netlify UI and retry the deploy to get a more verbose output from the build. This should be pretty rare so turning it on only when needed saves the additional time of the verbose build.

2 Likes

Really nice, thanks so much for sharing this for other folks who want to implement something similar

2 Likes

I just realised I hadn’t spotted an issue as I was originally testing this under the branch deploy context and in that case $BRANCH returns the actual name of the branch like cms/blog/2020-my-blog-name but when I run this under the deploy preview context then $BRANCH responds with something like pull/1234/head so the grep didn’t work.

I came across this page about available environment variables and tried out the $HEAD variable which worked for me in deploy preview context. Just thought I’d mention in case someone had the same issue.

2 Likes

@fool We set up a file called netlify-build-ignore.sh with the following contents:

#!/bin/bash

if echo $HEAD | grep "^module";
  then return 1
else if echo $HEAD | grep "^component";
  then return 1
else
  return 0
fi

The goal is to only build previews when the branch name contains “module” or “component”.
In netlify.toml we have:

[context.deploy-preview]
  ignore = './netlify-build-ignore.sh'

When the build runs, there is a permissions error: sh: 1: ./netlify-build-ignore.sh: Permission denied

How can we get an ignore script running from netlify.toml?

1 Like

Could you try bash ./netlify-build-ignore.sh as your command instead? Git doesn’t usefully save permissions so you can’t run an arbitrary text file like that, but bash ... can :slight_smile:

1 Like