Scope Vercel concurrency groups by project ID - #178
Merged
Conversation
The vercel-preview and vercel-production concurrency groups were keyed only on the PR number and the ref respectively. A repo that calls either workflow once per Vercel project put every call into the same group, so the projects fought each other instead of deploying independently. vercel-preview used cancel-in-progress: true, so the second job cancelled the first and only one project ever got a preview. vercel-production used cancel-in-progress: false, so the jobs queued; because GitHub keeps only one pending entry per group, a second push while the first run was in flight evicted the still-pending deploy and dropped it silently. Adding vercel-project-id to both group keys gives each project an independent group. Same-project behaviour is unchanged: previews still supersede on a new commit, production deploys for one project still queue in order. The PR comment marker had the same problem and is now scoped per project, so each project keeps its own comment instead of overwriting another's.
AdamJHall
approved these changes
Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of the proposed changes
vercel-preview.ymlandvercel-production.ymlkey their concurrency groups only on the PR number and the ref:The two failure modes:
cancel-in-progress: true) both jobs resolve to the same group, so whichever is admitted second cancels the other. Only one project ever gets a preview, and which one wins is a race.cancel-in-progress: false) the jobs queue rather than cancel, so a single push does deploy both. But GitHub keeps only one pending entry per concurrency group, so a second push landing while the first run is still in flight evicts the still-pending deploy. That failure is silent: green run, no deploy.The change
Add
vercel-project-idto both group keys. Each project gets an independent group, and same-project behaviour is unchanged previews still supersede on a new commit, production deploys for a given project still queue in order.