perf(deploy): build in parallel with test, deploy only assembles and pushes#3812
Merged
Merged
Conversation
Han5991
requested review from
cixzhang,
ejhammond,
imdreamrunner,
josephfarina,
marie-lucas,
nynexman4464 and
thedjpetersen
as code owners
July 11, 2026 10:37
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…pushes The deploy pipeline was sequential: test (~6min, including its own full build for the typecheck gates), then a deploy job that rebuilt everything again from scratch (~7min) before pushing. A merged PR took ~13min to reach the live site, and every main push burned two full builds back to back. Split the build out of the deploy job and run it in parallel with test: - build: full package build + Storybook + Sandbox (with the pinned Next.js cache, unchanged), uploads the site as three artifacts (storybook, sandbox, landing-page CSS), retention 1 day. - deploy: needs [test, build] — downloads the artifacts, preserves pr/ and reports/ from gh-pages, assembles the deploy dir, pushes. No Node setup, no rebuild. test still gates the push exactly as before; it just no longer serializes the build. Merge-to-live drops to ~max(test, build) + ~1min of assembly (~8min), and the shorter runs also reduce pending-run churn in the pages-deploy concurrency group. The artifact round-trip for storybook dist/ and sandbox out/ is the same mechanism ci.yml already uses for every PR preview.
Han5991
force-pushed
the
ci/parallel-deploy-build
branch
from
July 11, 2026 12:28
57e468d to
7948bbd
Compare
cixzhang
approved these changes
Jul 12, 2026
cixzhang
left a comment
Contributor
There was a problem hiding this comment.
Reviewed the full diff. Clean parallelization of the deploy pipeline: test and build now run in parallel and deploy only assembles downloaded artifacts + pushes — the test gate is preserved (needs: [test, build], push still requires test success), artifact round-trip paths are correctly rewired, least-privilege split (build is contents:read), and it mirrors the artifact mechanism ci.yml already uses. Well-evidenced with measured baselines and a fork validation run. Nice improvement.
cixzhang
added a commit
that referenced
this pull request
Jul 12, 2026
review-clear never actually cleared: it resolved the PR from workflow_run.head_sha, but for a workflow_run fired by a pull_request_review-triggered workflow that SHA (and the payload branch) point at main, not the PR — and pull_requests is empty for forks. So it always logged 'No PR resolved' and did nothing (e.g. #3812 stayed pending after approval). The triggering run's own head_branch IS correct even for forks (e.g. ci/parallel-deploy-build). Resolve the open PR by matching that branch (head=OWNER:branch, with a scan-by-ref fallback) instead of the useless head_sha.
cixzhang
approved these changes
Jul 12, 2026
cixzhang
left a comment
Contributor
There was a problem hiding this comment.
Re-affirming approval (verifying the fixed auto-clear path).
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
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.
Summary
The deploy pipeline was fully sequential:
test(~5–7min, including its own full build for the typecheck gates), then adeployjob that rebuilt everything again from scratch (~4–7min depending on Next.js cache) before pushing to gh-pages. Measured over the last six successful main runs, that put ~9.6–14.2min of execution (avg ~12min) between a merge and the site going live — plus queue time in thepages-deployconcurrency group — and every main push burned two full site builds back to back.This PR runs the build in parallel with test and turns
deployinto a thin assemble-and-push step. Merge-to-live drops to ~7.5min (measured, see below), and since wall time now converges tomax(test, build)the per-run variance mostly disappears.Measured baseline — recent successful main runs (job execution time)
The deploy job's spread (4.2–7.3min) is the redundant rebuild — the exact work this PR moves into the parallel
buildjob. On top of execution time, run totals include concurrency-group queue wait (e.g. run 29140874043: 11.1min execution but 17.2min created→finished), and 3 of the 10 most recent main deploy runs were cancelled as pending in thepages-deploygroup. Shorter runs shrink that churn too.Changes
build(new, parallel withtest): full package build + Storybook + Sandbox — identical steps to whatdeployused to run, including the pinned no-restore-keys Next.js cache (feat: XDS un-prefix migration — bare names canonical, XDS* compat aliases #2941 rationale unchanged). Uploads three intra-run artifacts (storybook dist, sandbox out, landing-page CSS), retention 1 day.deploy(needs: [test, build]): downloads the artifacts, preservespr/+reports/from gh-pages, assembles the deploy dir, pushes via peaceiris — no checkout of a build tree, no Node setup, no rebuild.testgates the push exactly as before; it just no longer serializes the build.pages-deployconcurrency group on a busy main.The artifact round-trip for storybook
dist/and sandboxout/is the same mechanism ci.yml already uses for every PR preview.Test plan
Validated end-to-end by dispatching this exact workflow on a fork (run, fork Pages disabled so nothing was published):
testbuilddeploytestandbuildstarted simultaneously and ran in parallel (both 10:27:00)deploywaited for both, then took 14s (download → preserve → assemble → push)storybook/,sandbox/,assets/(all 3 CSS files),index.html,latest,.nojekyll— expected layout, artifact contents intact