Automatically deploy branches that match name pattern

[tcardlab]

Say you frequently produce release/ branches or support/ branches where deployment would be useful. Is it possible to automatically add deploy branches matching ‘release/*’?

[luke]

@tcardlab, there are three options for this currently:

• All - Deploy all the branches pushed to the repository.
• None - Deploy only the production branch.
• add individual branches

There isn’t a wildcard option, though, which would allow matching only certain branches based on substring matches (like release/*).

We do have an open feature request for this. Is this what you are looking for? If so, please let us know and we’ll get this +1 added to the feature request.

[tcardlab]

I’m sorry, that feature request was also mine. After realizing it was not currently supported, I wanted to go through the official route and properly suggest the feature.

If you don’t mind, I do have three followup questions while I try to circumvent the issue:

If I were to add individual branches:

1. Is it possible to programmatically add branches to netlify.toml via lambda function, cms git-gateway, or some other way?

If I were to choose All:

2. Branch accessibility is important to me. Are all branches given a predictable subdomain, such as the branch name, or is that only the case when added individually?
3. It was noted here, that a [skip ci] tag can be used to skip commits. I assume there is no equivalent for branching?

[futuregerald]

Hi @tcardlab,

1. The netlify.toml needs to be there in your repo at the beginning of your build. The only way to do this programmatically via a lambda function would be to create the file and commit it to your git repo using a function. This is possible but you’ll be writing this code yourself. It’s possible to do this using Github’s API.
2. All branches deploys have a branch subdomain that’s preditable. It includes the branch name. A branch deploy URL will always point to the latest deploy for that branch.

[tcardlab]

@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!

[davidyeiser]

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?

[fool]

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:

Netlify

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:

[Support Guide] Understanding and using Netlify's API

Last reviewed by Netlify Support staff: August 2023 Did you know that Netlify has an extensive public API? Anything that you configure in our Admin UI at https://app.netlify.com is managed using this same API, and you’re welcome to use it to create and configure your site(s) and perform most other operations on your account. We have an article on API Usage in our official documentation which shows how to do some common tasks like deploying your site and configuring it in great detail. It also …

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

[szpak]

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.

[jen]

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

[afontcu]

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!

[luke]

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

[slorber]

+1 vote, just to track this issue

[perry]

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

[TerryDC]

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

[jen]

Thanks, @TerryDC- added!

[ahtcx]

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

[Scott]

Understood & added, @ahtcx!

[knoxjeffrey]

+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.

[fool]

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

[knoxjeffrey]

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.