vercel
Feature request: Ignored branches for deploy previews
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 https://github.com/opencollective/opencollective-frontend/pull/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.
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
Deploys happen on push, not on commit.
Is it possible to adjust your tool to only push once for the PR?
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).
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?
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 [email protected], so that we can consider adding it to our roadmap.
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 [email protected], 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.
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)
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.
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)
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?
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!
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.
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.
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)?
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)
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.
@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.
related discussion here https://github.com/vercel/vercel/discussions/5171
They published this 2 days ago: https://vercel.com/knowledge/how-do-i-use-the-ignored-build-step-field-on-vercel
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.
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.
Can you elaborate? I've tested the example again and it worked as expected.
Personally I haven't tried yet if this works or not, but the implementation sounds bizarre to me.
If the command returns what is conventionally the success exit code (0) the build will halt, whereas if the command returns what is normally an error code (1), the build goes ahead?
Anywhere else, a command that fails with a non-zero exit code would stop the build.
@deakster Think about the command in its most common use-case:
If git diff (...) returns something, the build must continue. If not, you halt it.
@paulogdm Ok, not a big deal to me although the command we are running to determine build progress is not "git diff" in our case.
I think @alpapp is correct that it doesn't work though. The blog post here suggests that the BRANCH environment variable is available and can be used, but this does not seem to be the case for us. We are running a very simple node script like node buildcheck.js, and when we print out the entire contents of process.env there is nothing there indicating the BRANCH.