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.
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.
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:
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
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 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.
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
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:
command = '''
if echo $BRANCH | grep "^cms" ;
then NO_CONTRACTS=true RUBYOPT=-W0 middleman build $CMS_PR_BUILD_OPTIONS
yarn test && RUBYOPT=-W0 parallel_rspec -n 2 spec && NO_CONTRACTS=true RUBYOPT=-W0 middleman build --verbose
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.