Feature request: Ignored branches for deploy previews

[Betree]

Hi there!

Zeit deploy previews are awesome, it's definitely an essential feature for our workflow at Open Collective.

We're using a tool called Crowdin to manage our translations. This tool creates a lot of commits, sometimes hundreds in the same day (see opencollective/opencollective-frontend#2824). Deploys preview don't really matter for the pull requests created by this tool and we would prefer to not flood our Zeit pre-deploys with it.

Proposed solution

In now.json, add a deploy-previews fields that would accept an exclude parameter like this:

{
  "version": 1,
  "name": "opencollective-frontend",
  "type": "docker",
  "deploy-previews": {
    "exclude": ["i18n/crowdin"]
  }
}

Now would then not deploy any branch matching the names given in this array.

Bonus: allow wildcards in names (ex: i18n/*) - not required in our use case, but could be nice.

[Betree]

As an alternative, an exclude-labels setting with a list of labels that will prevent Zeit from deploying would do the job just as fine

[styfle]

Deploys happen on push, not on commit.

Is it possible to adjust your tool to only push once for the PR?

[Betree]

We can indeed change the push interval to reduce the frequency (1 per day for example) but that's not very convenient for us as we often want do last-minute translations before the releases so we like that it's pushing things fast (currently up to 1push/10minutes).

[styfle]

It looks like you are still using Now 1.0 which is typically slower than Now 2.0 because it has to build a complete docker image.

Have you considered upgrading to 2.0?

[leo]

Thank you for creating this issue!

Please note that – in order for us to be able to handle each feature request with care – we have to consume all of them through a unified pipeline that makes it easier for us to prioritize, track and progress on the features our user base is interested in.

In turn, the Issues tab on this repository is best only be used for reporting bugs, which we can immediately act on.

For well-explained feature requests (like the one you just posted), please contact us at support@zeit.co, so that we can consider adding it to our roadmap.

[Betree]

It looks like you are still using Now 1.0 which is typically slower than Now 2.0 because it has to build a complete docker image.

Have you considered upgrading to 2.0?

Sorry for the late reply! I'm not the one working on it, but it seems that we can't update to 2.0 because we're using express.

Thank you for creating this issue!

Please note that – in order for us to be able to handle each feature request with care – we have to consume all of them through a unified pipeline that makes it easier for us to prioritize, track and progress on the features our user base is interested in.

In turn, the Issues tab on this repository is best only be used for reporting bugs, which we can immediately act on.

For well-explained feature requests (like the one you just posted), please contact us at support@zeit.co, so that we can consider adding it to our roadmap.

Before posting this issue I also sent it on the "Feedback" box on Zeit but didn't received any reply.

I think having a public place to show feature requests is great, because it allows people to +1 rather than writing a full feature request for something that was already asked. People can subscribe, and by replying on it everyone's gets the info about whether or not this will be done/prioritized.

That being said, it's understandable that you may want to prefer tracking everything on a single (private) tool to organize better.

[Andre601]

Is this a thing now, or still planned to perhaps be implemented, as I myself would like to have this, to prevent ZEIT now from deploying changes when pushed to the gh-pages branch (Which may cause errors apparently)

[njbarrett]

I'm still interested in this feature, has anything happened with it?

[ay8s]

Would love this also.

[mediabeastnz]

This would be a great feature. I vote for whitelist approach.

[clement-faure]

Same here, would love this.

[styfle]

This feature is available today, called Ignored Build Step. You can write a custom script to ignore or allow builds after you git push, for example ignore a certain branch.

[Andre601]

This feature is available today, called Ignored Build Step. You can write a custom script to ignore or allow builds after you git push, for example ignore a certain branch.

As much as this is an option does it require some git knowledge which not everyone heee might offer (also, why am I still subscribed to this? I don't use this anymore)

[MatyiFKBT]

This feature is available today, called Ignored Build Step. You can write a custom script to ignore or allow builds after you git push, for example ignore a certain branch.

How would you exclude a branch with this feature?

@styfle Could you please show an example?

[njbarrett]

An example is required here please @styfle

[alpapp]

Yes please, an example. I want to prevent preview builds of the "development" branch of my project. What command must I use in this Ignored Build Step facility?

Another use case might be preventing all builds except for the master branch.

Any examples welcome!

[magic-akari]

I tried the following command, but it doesn't work.

[[ $(git branch --show-current) = "gh-pages" || $(git diff --quiet HEAD^ HEAD ./) ]]

Maybe the command need to be wrapped with bash -c.

[njbarrett]

I have tried similar commands to the above, but turns out that git branch --show-current is always returning master even when the deployment is for another branch.

I found this out by creating a shell script that runs before the build and echoing the value out.

[alpapp]

Searching google, the following command returns the most recently committed ("pushed" / "synced" ?) branch:
git for-each-ref --count=1 --sort=-committerdate refs/heads/ --format='%(refname:short)'

How do we structure this such that the Ignored Build Step function can return a 1 (for make a build) or 0 (ignore it) when it = "master" (or some other branch of your choosing)?

[alpapp]

I knocked up a quick nodejs script to exec this command and, as @njbarrett has found, Vercel always returns "master" as the local branch even though the beginning of the build log shows it's coming from another branch. It would seem the local build environment always places the pulled down code into it's own master branch and that is that.

Vercel team - how can we determine reliably which remote branch the Vercel build process is building for, in code, within the Ignored Build Step command? As previously established, git branch --show-current and similar all return "master" no matter the originating branch. (Querying the remote is only a partial solution as it may be a private repository and unwilling to expose login information within IB script)

[alpapp]

Further research indicates that the System Environment Variable VERCEL_GITHUB_COMMIT_REF should contain the branch name that triggered the build process, accessible via process.env.VERCEL_GITHUB_COMMIT_REF provided you've added it in the project Settings page under Enviroment Variables. However, I can't get it read anything if used within the Ignored Build Step script (but does read OK within the normal build step that subsequently ensues). It would seem to me that the env variable is not set for the Ignored Build Step before the actual build is performed, and hence is not useable for this purpose.
System Environment Variables doc page refers.

[njbarrett]

@alpapp I came to similar conclusions also. So my work around for now is to check that env variable in the build step and fail the build if that env variable equals one I dont want it to deploy. So I haven't "ignored" the branches but they will error.

Hopefully someone from Vercel can chime in as to a proper solution using the feature they claim as the solution.

[styfle]

Thanks, we'll get this fixed and document a proper solution!

[michaelbirchler]

related discussion here #5171

[MatyiFKBT]

They published this 2 days ago: https://vercel.com/knowledge/how-do-i-use-the-ignored-build-step-field-on-vercel

[alpapp]

Yes indeed, except their example script doesn't work as it implies it should. Any commit to any branch triggers my build, which is clearly not how it's supposed to be.

[ccrvlh]

Any news on this? All of feature branches are being deploy in Preview, it seems that this is a waste of resources actually (build time), both for us and for Vercel. As someone mentioned, could be as simple as choosing a production branch, and preview branch. Doing it the other way around, "Ignoring", would be complex and not friendly since it would require some regex since new branchs with different names and name patterns are create frequently.

I would be more than happy to have production running with master and preview running with develop for example, simple as that. There could even be a possibility to make more complex rules for production/deployment available only on more expensive plans.

[preeteshjain]

This is a no-brainer, must have feature that saves time, money and resources for both Vercel and users.

Please implement this ASAP.

[lorenzodejong]

+1, the proposed solution from @magland works fine overall. However i've noticed that (when using the Github integration) the Github Deployments API is called even though the deployment is canceled from the "Ignore build step" setting. This is especially annoying when using integrations like Github for Slack, because a "Vercel deployment" Slack notification is still triggered even though the deployment is canceled right after starting the deployment run.

I would really like to see first-class support for limiting deployments to specific branches.

[ImOnMars]

It's confusing how some of the simplest features that anybody would expect to exist just don't sometimes. Surely adding a couple of toggles and an optional whitelist of branches would be rather straightforward and distinctly essential for a platform that emphasizes developer-focused ease of use and accessibility.

[s-en-o]

It's confusing how some of the simplest features that anybody would expect to exist just don't sometimes. Surely adding a couple of toggles and an optional whitelist of branches would be rather straightforward and distinctly essential for a platform that emphasizes developer-focused ease of use and accessibility.

I think It can be an option on what branch we want to deploy.
i.e:

• Want to deploy f-staging branch to a staging domain
• Want to deploy f-someFeature branch to a feature domain
• And of course your production branch from main or master will deploy to primary domain

Other than what branches we have already added to the list do not deploy.

[elnelsonperez]

It is surprising to me how this issue is still open after three years.
Is it that hard to implement?

[dgurns]

Completely agree with the comments so far. I have silent: true implemented, as well as Ignore Build Step, but I still see the bot deploy messages on my PR -- even though nothing is being deployed.

I'd propose that if a build has been skipped, then the Vercel bot should not post a deploy message on the PR.

Any chance of implementing that, Vercel team? (Love the product otherwise)

Outside of that change, anyone been able to figure out how to silence this?

[KaneLabs]

I understand dev time is a scarce resource but now we can't use vercel for our monorepo because of these limitations.

[msw93]

Any updates on this feature? A potential timeline for resolution?

[b-lov]

only missing feature, that makes me use netlify over vercel

[stvnbash]

It would be a great feature to be able to select specific branches for Preview Deployments similar to how we already can select a branch for Production Deployments. I commit/push relatively frequently as I'm developing--and I don't need every push on development branches creating a new Preview Deployment.

[lucavenir]

I'm honestly surprised this is not a thing as today. It just makes sense to select which branches I need to build and spend resources on, as most of the times as a developer I just work on feature or local development branches. Just because I'm pushing some changes doesn't mean that I need a live preview of a dev branch. Or at least this should be customizable.

[rayjasson98]

Another problem is that any failed/ignored build step will appear as a "Build Cancelled" deployment in the build logs. This makes it quite hard to find out which deployment succeeds or fails, as you will need to rummage through all those "Build Cancelled" logs.

[tobiastornros]

Would be nice to have deployments only for open PRs, staging and production.

[hormesiel]

Here's a simplified version of the command in the previous comments to use in Ignored Build Step :

[ $VERCEL_GIT_COMMIT_REF != "preview" ] && [ $VERCEL_GIT_COMMIT_REF != "production" ]

This will trigger (i.e. not cancel) new deployments for the preview and production branches only.

[ghost]

With Firebase backend, it is necessary to specify the domain to use App Check and recaptcha, so it is stressful that it will be deployed every time you commit and an authentication error will occur, so please solve it as soon as possible.

[liblaf]

Maybe the git.deploymentEnabled option in vercel.json would do?

[oliversturm]

Potential paying customer reading here... off to try the suggested workarounds now, but ... seriously? Doesn't look promising for your support that a simple and obviously required feature like this is not implemented after 3.5 years.

[vincentjflorio]

I would also like this; I appreciate that I don't know the magic behind the scenes that it might take, but in my layperson brain it just seems like it'd be a covered base.

"Here is a thing, and here is what you can do it to."

For various other non-Vercel reasons I need to update my repo, pushing things from local to GitHub so I can't stop doing that.

If Vercel isn't in a position to stop from building each one it sees, is there perhaps a means on GitHub of hiding from Vercel on a per-branch basis? :)

[qrkourier]

This has been a thorn in my side despite the availability of ignoreCommand in vercel.json and "Ignored Build Command" in Git settings.

The problem is that vercel.json isn't available on the branch I want to ignore, so I must use project settings, not vercel.json to configure the ignore command, and the "Ignored Build Command" BASH test doesn't seem to have access to the branch name in VERCEL_GIT_COMMIT_REF, despite having opted-in to "Automatically expose System Environment Variables" in "Environment Variables" settings.

My ignored build command in "Git" "Project Settings":

[[ "${VERCEL_GIT_COMMIT_REF}" =~ ^(gh-pages)$ ]]

[alexander-mart]

Answer in docs:
https://vercel.com/guides/how-do-i-use-the-ignored-build-step-field-on-vercel#with-a-script

@leo this issue can be closed? :)

[preeteshjain]

@alexander-mart No, this cannot be closed. This is not the ideal solution if you have read the comments above. This is feature request, and Vercel hasn't addressed this yet. Read #3166 (comment)

[yannispgs]

Vercel team does not seem to take Feature Requests from this Repository Issues. Maybe the creator of the issue (@Betree) or someone else in this topic could create such post in the dedicated section.

If the newly created post managed to have lots of likes/thumbsups, maybe the development team will pay more attention to the matter.

I already opened a case that could match with some of the above use cases for those who seek a more powerful git.deploymentEnabled feature.

[ShanArosh]

It seems we would have to rely on scripts for a long time.
If anyone is using Turborepo and wants only to allow certain branches to be built, feel free to use this script as Ignore Build Command.

build command

bash <path-to-script.sh>

bash script.sh

script.sh

#!/bin/bash

echo "VERCEL_GIT_COMMIT_REF: $VERCEL_GIT_COMMIT_REF"

if [[ "$VERCEL_GIT_COMMIT_REF" == "main" || "$VERCEL_GIT_COMMIT_REF" == "sandbox"  ]] ; then
  if npx turbo-ignore 2> /dev/null; then
    # Don't build
    echo "🛑 - Build cancelled"
    exit 0;
  else
    # Proceed with the build
    echo "✅ - Build can proceed"
    exit 1;
  fi
else
  # Don't build
  echo "🛑 - Build cancelled"
  exit 0;
fi


# https://vercel.com/guides/how-do-i-use-the-ignored-build-step-field-on-vercel

This script will only build if the branch is main or sandbox and npx turbo-ignore leverages the Turborepo dependency graph to automatically determine if each app, or one of its dependencies has changed and needs to be deployed.

[walsha2]

The problem is that vercel.json isn't available on the branch I want to ignore, so I must use project settings, not vercel.json to configure the ignore command

@qrkourier This is 100% the issue and why @preeteshjain says this needs to be a feature. The current Ignored Build Command logic is way too limiting and does not/cannot handle every case.

The gh-pages issue is particularly annoying. The gh-pages branch does not have any source code typically, so there is no vercel.json or bash script that can be executed. Further, the Root Directory that Vercel expects likely does not exist on that branch. Attempts at setting the value in the Vercel project settings does not work either. No matter how many times I try, this never works because it errors out saying the expected deployment location cant be found. Its almost like it checks Root Directory setting BEFORE it checks Ignored Build Step which is odd.

echo $VERCEL_GIT_COMMIT_REF; if [ "$VERCEL_GIT_COMMIT_REF" == "gh-pages" ]; then exit 0; else exit 1; fi

A nice solution for the community is to simply allow Project level settings to explicitly ignore certain branch names, or expand this Ignored Build Step logic to more than its simplistic one-line input. Relying on vercel.json or a script in the branch to exist is not viable for all use cases.

---

TLDR: TheIgnored Build Step feature in Vercel needs to be expanded. Please stop referring users with this issue to the existing docs or examples. They do not solve the problem.

[bezugen]

any news on this issue? it's one of the most commented issues, it's already 4 years and it's still happening :-(

[nextor2k]

It's almost 2024, and this feature still needs to be corrected!