Hi @dthreatt,
Can I ask, please, what you’re trying to accomplish?
If you just want to use a staging frontend vs your staging env in Dato:
Sorry for the lack of clarity here, but your build hooks are not environment-specific, they are shared across your whole project.
Typically, you can make different frontend environments just by using Git branches and specifying an X-Environment
header in your fetch.
As an example, I cloned our Next.js starter project, then made a staging
branch for it:
The only real difference is that it specifies 'X-Environment': 'staging'
during the query fetch. Once I commit and push that branch, Vercel will automatically create a new deployment for it:
That will build the staging branch on a new subdomain:
Does that help? Is that what you’re trying to do?
If you specifically want another build trigger just for staging:
If you want to make a custom build trigger inside DatoCMS specifically to rebuild your staging branch from the Dato UI, I think you can do that by making a custom Vercel build trigger: Creating & Triggering Deploy Hooks
That’d be a custom hook you manually invoke, vs the default Vercel integration that we provide for your production env.
But it’s probably cleaner to just push your staging branch to Vercel on a code change, and that way it will automatically deploy…?
You shouldn’t need to re-build the whole site on a content change (either on production or staging). If you’re doing static builds, Incremental Static Regeneration should let Vercel auto-detect changed content and regenerate just the relevant pages, instead of needing a manual redeployment of your whole codebase.
That overrides the fetch()
function with an invalidation timer, after which Vercel will check the fetch against its internal caches and automatically rebuild the affected pages if necessary, without needing a manual redeployment.
I hope I understood you correctly…? If I missed something, could you please clarify?