Is there no way to block all automatic deployments from github?

We have a GitHub connected project. We manually deploy to both preview and production via the CLI, and thus we don't want Vercel to run any deployments automatically.

Branch tracking is disabled:

Ignored build step:

Our vercel.json:

{
    "git": {
        "deploymentEnabled": false
    }
}

Yet when a PR is made, Vercel reports that the deployment timed out. However, our manually triggered deployment via the CLI (via GH Actions) is clearly passing. Why is Vercel still attempting to create a deployment? It's also preventing us from merging. Similar issues here and here.

Expected behaviour: Vercel should simply never deploy by itself. Deployments should be triggered only when a CLI call is made.

Vercel Staff

There are a lot of config choices here that could result in overly restrictive build cancelations.

I would recommend setting git.deploymentEnabled option to false in the vercel.json config to turn off all automatic deployments. You may need to make a deployment to get the new config established, then I would expect that any future GitHub commits not to trigger an automatic deployment. You may also want to change the Ignored Build Step back to Automatic to avoid unintended canceled builds.

The solution to the "Merging is blocked" issue from the other discussions you linked was to change GitHub some repo settings: https://github.com/vercel/community/discussions/3215#discussioncomment-6969235

GitHub

Merging is blocked - Missing successful Production deployment · vercel/community · Discussion #3215

Problem Description On Pull Requests, I'm seeing Merging is blocked - Missing successful Production deployment I can see the Preview Deployment and link, though. Is this expected, and is there any ...

I hope that helps!

Thank you for the response; git.deploymentEnabled is indeed set to false as I mentioned in my original post. We have tried having Ignored Build Step be both Automatic and Don't build anything, which doesn't seem to make a difference.

I've tried fixing the capitalization issue mentioned in the discussion you posted, by deleting our GitHub environments, updating the workflow, and pushing it to a PR. This resolved the "failing check" but the merge is still blocked:

Note here that Preview - Branch Tracking is set to Disabled. Capitalization:

Here's another attempt where Preview - Branch Tracking is set to Enabled:

Merging remains blocked but Vercel no longer comments Creating the Deployment Timed Out.

Vercel Staff

Thanks for trying that. I haven't been able to replicate this issue with my own repo. Do you have a public repo that I can use to investigate?

Sure, thanks for the effort! ~~Invited you to [redacted].~~

It appears the issue has resolved itself...not sure why as no changes were made since my last test.

My final settings if anyone else comes across this post:

Fixed capitalization as mentioned here: https://github.com/vercel/community/discussions/3215#discussioncomment-6969235

GitHub

Merging is blocked - Missing successful Production deployment · vercel/community · Discussion #3215

git.deploymentEnabled option set to false in vercel.json
Ignored Build Step set to Don't build anything
Environments -> Preview -> Branch Tracking set to enabled (I think enabling this is what most possibly did it?)

An alternative solution: Instead of enforcing a successful deployment, one could enforce only the status check of the deployment.

This topic is closed. It no longer accepts new replies.

It appears the issue has resolved itself...not sure why as no changes were made since my last test.

My final settings if anyone else comes across this post:

Fixed capitalization as mentioned here: https://github.com/vercel/community/discussions/3215#discussioncomment-6969235

GitHub

Merging is blocked - Missing successful Production deployment · vercel/community · Discussion #3215

git.deploymentEnabled option set to false in vercel.json
Ignored Build Step set to Don't build anything
Environments -> Preview -> Branch Tracking set to enabled (I think enabling this is what most possibly did it?)

An alternative solution: Instead of enforcing a successful deployment, one could enforce only the status check of the deployment.