Multiple deploy-preview contexts

Is it possible to have multiple deploy-preview configurations, or to override deploy-preview settings contingent on branch?

We would like Deploy Previews for PRs to our master branch to use production data, while Deploy Previews for PRs to all other branches should use staging data.

Thanks!

hey there, i think i understand what you are hoping for, which sounds a lot like deploy contexts:

will you give this a read through and see if it meets your needs?

Yes, we’re using Deploy contexts. What isn’t clear to me is how to use overrides that “are applied in a hierarchical order” (quotation from your link) to achieve this.

For example, we essentially have:
[context.production.environment]
FOO = “BAR”
[context.staging.environment]
FOO = “BAZ”
[context.deploy-preview.environment]
FOO = “BAT”

If we remove the FOO=BAT from deploy-preview, the build fails because no value of FOO is present.

We want our Deploy previews to use FOO=BAR if it’s a production preview (PR to master branch) and FOO=BAZ if it’s a staging preview (PR to different branch).

Is there a way to achieve this?

For hierarchy to work, you need to specify a fallback. In what you’ve shared above, you’ve not added generic contexts, you’ve set absolute contexts.

So, context.production.environment will only work for production and would not be used as a fallback.

Instead,

build.envionment would set it for all generic deploys.
context.staging will override it for branch deploys, but will use build.environment if nothing found.
Same for deploy previews.

But I’m not sure if this will help in your use case. You want to differentiate between deploy previews based on branch. I think we will treat all deploys previews as deploy previews and thus, they would use the same context.

Thanks for your response. I think you’re right. Could Netlify prioritize some mechanism to support this usage? It would make a wonderful experience for us to remove our “production-preview” branch (created for this use) and have one less branch to merge through.

We can pass this on to the team, but can’t talk on prioritisation as that’s not something the support team decides. The product team considers all feedback and more factors before deciding on what to prioritise, and I’ve seen this being requested for the first time. Not saying no one needs this feature, but maybe others have gotten around this limitation just like you’re planning to. So, this doesn’t seem like something that might change in the coming months.