I’ve noticed that using the Vercel-Supabase integration triggers duplicate deployments on PR open.
In discussion with Vercel support, my understanding is the integration automatically redeploys the most recent deployment to ensure that all environment variables are properly reflected, which can sometimes lead to duplicate builds.
I’d like to suggest something like a configurable option to delay builds until integrations (such as Supabase) complete their updates, in order to prevent unneeded builds (and the downstream effects of those builds, e.g. webhooks triggering other systems like GitHub actions).
USE CASE
This came up because I use GitHub actions to run e2e tests in response to the vercel.deployment.success event. When a PR is opened, the Vercel-Supabase integration automatically triggers a redeploy of the same commit from the PR, causing two vercel.deployment.success events, resulting in duplicate e2e test runs.
The integration is needed because it sets environment variables for Supabase ephemeral branches.
I have a workaround using concurrency controls to cancel duplicate test runs, but the duplicate deployments still appear e.g. in the Vercel dashboard, GitHub actions, etc…
It’d be ideal if there was some way to control which of these two builds I actually need, and have the other one cancel (or even better, never run). In my case, I need the 2nd one, once the env variables for the ephemeral database branch have been set.
I attempted to ignore / cancel the unwanted build using Vercel’s “Ignored Build Step” feature with a bash script, but was unsuccessful because it seems like there’s no way to determine what triggered the build from within the build script environment.