Deploy Contexts configured for Staging subdomain, but deploys to staging branch are publishing Master branch code

Hi guys.

I have Staging set as a context and a branch to match, with a netlify.toml file that declares different Contentful API credentials for both Production (master branch) and Staging, but when I push changes to the Staging branch, it automatically deploys the code and content from the Master branch.

I’m super confused because there are significant changes between the two and I’m trying to preview new changes on the staging site prior to deploying to production.

Here are the contents of my netlify.toml file…

  command = "echo 'Deploying to PRODUCTION'"
  environment = { CONTENTFUL_ACCESS_TOKEN = "[redacted prod key]", CONTENTFUL_ENVIRONMENT = "master"}

  command = "echo 'Deploying to STAGING'"
  environment = { CONTENTFUL_ACCESS_TOKEN = "[redacted staging key]", CONTENTFUL_ENVIRONMENT = "staging" }

Also, my publish directory is set to “public” as that’s where Gatsby builds the project. I am able to deploy successfully to Production with this setting. However, when deploying to Staging it fails with the error “failed during stage ‘building site’: Deploy directory ‘public’ does not exist”. I had to set the publish variable to “public-staging” in order to get it to succeed.

Maybe I’m missing something completely, but clearly I’m misconfiguring something. Please help.

Anybody have issues with this or see anything obvious that being misconfigured? I still cannot figure out why this is deploying the master branch to all branch subdomains.


Hey @matthewamundson, thanks for your patience on this.

I’m not familiar with the configuration you shared for integrating Contentful with Netlify. If you want to send your Netlify URL, we can try to help you debug from the Netlify side.

In the meantime, what I’m more familiar is something like this, which has the added benefit of not putting tokens in a netlify.toml that may accidentally get pushed to GitHub:

  • set up your Contentful API keys (CONTENTFUL_SPACE_ID and CONTENTFUL_ACCESS_TOKEN)
  • add them in the Netlify UI. You’ll do this in your site dashboard under Settings > Build & deploy > Environment > Environment variables
  • add build hooks in Netlify UI (it seems like you’ll want one for each branch, staging and master):
  • add webhooks in the Contentful UI to hit the Netlify build hooks. You’ll drop in the URLs generated in the Netlify build hooks UI.
  • update content in Contentful and see it get pushed to Netlify!

I believe Contentful also a Netlify app integration, though we can’t really troubleshoot the Contentful side. But I did want to let you know it could be something to check out.

Hi @jen, thanks for the reply.

My concern isn’t necessarily the details of Contentful or the security of the keys in the netlify.toml file (though I hear you and agree), but more about the configuration of variables, netlify.toml configuration, and correct deployments to branch subdomains. Does the syntax in my original post look correct to you in order to deploy correctly to different subdomains? If so, it’s not working, and the master branch code is being deployed to staging as well. They are visually very different UIs, but when I view the staging URL I’m seeing the exact UI that’s on the master branch.

Second, The keys and access tokens are different per Contentful env. If I’m understanding your suggestion correctly, that I should add each set of keys per environment to the Netlify Environment variables list, (CONTENTFUL_SPACE_ID_staging, CONTENTFUL_SPACE_ID_production, etc) it means I’ll have to do conditional checks in the code which I’d argue is not good practice to put environment/server-specific logic into the application.

Thoughts? Appreciate your help.

One thing that might help you is printing your environment variables- you can add env to the beginning of your build command (env && gatsby build) and the build logs will print your variables so you can see if they’re what you expect.

Beyond that, if you could share your Netlify URL, that’ll let us dig into your build logs that are failing :slight_smile:


Site URL:

Gah! Sorry @jen, this was simply an issue of the branch subdomain also configured as a custom domain alias, so it was just a routing issues.

All fixed after removing that record and just relying on the branch subdomain setting.