When we launched Vercel for GitHub in June last year,
our goal was to provide you with an easy way to deploy your latest changes
without any extra effort. The Vercel for GitHub integration allows for a seamless
workflow if you use GitHub for collaboration and Vercel for deployments.
Going forward, every successfully deployed commit within a Pull Request gets a
staging label, as well as a View Deployment button next to it. This makes it easy
for you to quickly verify the build against every single commit.
GitHub's Deployment API
makes it possible to pass the URL of a successful Vercel deployment to other GitHub integrations that wait on a deployment to run.
Thanks to that, one can now run automated tests upon deployment, and use the
results from the tests to determine if a Pull Request should be merged.
There are 3rd party services available to help with the automated testing.
If a Pull Request made from a forked repo to the parent attempts to
update vercel.json, we now fail the build and request an authorization from the parent repo.
This ensures that we only build for commits that are anticipated and helps keep
the source files further secure.
Previously, if a forked repo had Vercel for GitHub set up,
we would deploy commits pushed to the forked repo. This has sometimes led to conflicting
deployments, as well as errors with aliasing. To prevent this, we now only build commits on
the parent repo. If Vercel for GitHub is set up on the
forked repo, commits pushed to the forked repo don't build and deploy unless they're a part
of a Pull Request to the parent repo.
By preventing builds on forked repos, we are now able to avoid confusing aliasing errors such as the one
Our mission at Vercel is to make the cloud accessible to all. In the case of developers,
one way we do this is by raising the industry standard for developer experience.
Vercel for GitHub is a big part of that initiative,
and we welcome any feedback, ideas or suggestions through our