Greetings. Is it possible to generate a deploy preview (unique context) on a ‘production branch’ without using a Pull Request or a separate branch?
I would like to generate a preview build (build and deploy-preview) on a production branch without altering the deployed site (and without using a PR or branch). Can this be done with the current solution? Can this be done programmatically with the OpenAPI? Or, perhaps it’s not possible to build and deploy a preview without a separate PR or branch?
Then new deploys will still occur and be available at the URL with the deploy id in the subdomain, a URL with a domain name like 5e19aa772269ffd1b10a7341--subdomain.netlify.app.
The new deploys still happen but they do not become the “published” version of the production branch when the published deploy is locked. You can then manually publish them or unlock deploys again when you do want to update the production version of the site.
If that doesn’t meet the requirements or if there are other questions, please let us know.
I can see how we can configure the locked setting in the UI and in the API. This might be a sufficient option. Can this locked state be set via other configuration options? Now looking for configuration file settings or even a way to configure via a Build Hook.
Hi, @tempest-mind. The web UI or API are the only ways to do this now. Note, the web UI is also using the API so locking and unlocking via the web UI and using the “copy as curl” option in devtools is one great way to get working example. The example then can be used to do the same in a language of your choice or just using the curl example in a shell script.
As far as having a web hook to toggle this, you can do so using a third-party service like Zapier. You can create a webhook there (unauthenticated) which then triggers the API call with the API key (authenticated) when the webhook is called.
You could either have two webhooks (for lock and unlock) or include a GET step to check the state and then toggle in the code that makes the API call. You might even add an option to pass a site-id with the webhook so it could be used for all sites on your account.
Then again, you might just write a script used as part of your deploy process to call the API directly.