chore(ci): check build memory against vercel machine size - #4657
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| # Smallest fixed tier this build fits on under the threshold. Falls | ||
| # back to Turbo, the largest, when nothing fits. | ||
| RECOMMENDED=$(awk -v peak="$PEAK_GB" -v t="$THRESHOLD_PCT" 'BEGIN { | ||
| split("Standard:8 Enhanced:16 Turbo:60", tiers, " ") |
There was a problem hiding this comment.
The PR description says there's no hardcoded capacity to keep up to date, but the dropdown only carries the tier name. The capacities are literals here and again in the case below, and the tier count is hardcoded a third time as the i <= 3 bound.
The values are all correct against Vercel's current specs, so nothing's wrong today. It's the next change I'd worry about: patching the case but not this string gives you a correct pass or fail with the wrong recommendation, and adding a fifth option to the dropdown would fall through to Turbo without anyone noticing. Could both halves read one shared tier table instead? Worth fixing the claim in the PR body too, since that's what someone reads first when they come to update it.
| run: /usr/bin/time -v -o build-memory.log npm run build | ||
| shell: bash | ||
|
|
||
| - name: 📊 Report Against Machine Capacity |
There was a problem hiding this comment.
This step has no if:, so it inherits success() and gets skipped whenever the build fails, and build-memory.log isn't uploaded anywhere so it goes away with the runner.
That's worth keeping, because the log still has the number in it. GNU time writes its whole report before working out its own exit status, so an OOM-killed build leaves the peak RSS in the log with a Command terminated by signal 9 line in front of it, and exits 137. The awk match already tolerates that preamble. So if: always() plus an upload-artifact step would get you the figure in the case where it's least ambiguous.
| - name: ⚙️ Use Node.js 20 | ||
| uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0 | ||
| with: | ||
| node-version: 20 |
There was a problem hiding this comment.
I think Vercel is building this on Node 24, not 20. Their docs say engines.node overrides whatever's picked in Project Settings, and their mapping table puts >=20.0.0 in the 24.x row, resolving to the latest 24.x. This repo's package.json declares exactly that.
If that's right, the measurement is on a different major than production, and GC behavior moves between majors enough to undercut the comparison. The quick fix is node-version: 24. A committed .nvmrc that both this workflow and Vercel read would be the durable one, since there's no .nvmrc or Volta pin right now.
| split(tiers[i], tier, ":") | ||
| if (peak / tier[2] * 100 <= t) { print tier[1]; exit } | ||
| } | ||
| print "Turbo" |
There was a problem hiding this comment.
Nit: when nothing fits under the threshold this prints Turbo, which is also the largest tier, so on Turbo you'd get "Move to Turbo before releasing", and the Elastic warning would say the build fits on Turbo when it doesn't. It needs a peak over 45 GB to get here, so it's out of reach on a 16 GB runner today. A distinct "nothing fits" value would stop the message claiming a fit that isn't there, but up to you, this is cosmetic while the runner is the ceiling.
2 participants
Issue URL: N/A
What is the current behavior?
No workflow builds the site. CI.yml lints, runs tests, spellchecks, and checks translation keys, but never runs
npm run build.Vercel preview deployments do build, but
build:previewisdocusaurus build --locale en, so the Japanese locale is only ever built by production. That means nothing before a merge exercises the full build, and nothing measures how much memory it needs. There is no signal ahead of a release about whether the build still fits the Vercel build machine.What is the new behavior?
Adds a manually triggered workflow that measures the full production build and compares it against the Vercel build machine the project is pinned to.
It builds all locales on Ubuntu, records peak memory with
/usr/bin/time -v, and emits exactly one annotation:The machine tier is a dropdown input, so there is no hardcoded capacity to keep up to date. Elastic is reported rather than checked, because it sizes each build from recent successful builds and has no fixed capacity to compare against.
Run it before a release. Adding a documentation version is what moves the number, so that is when the answer matters.
Does this introduce a breaking change?
Other information
Why this exists. The v9 release pushed the production build past the 8 GB ceiling of Vercel's Standard machine, and three consecutive production deploys were killed partway through the Japanese locale. Preview builds stayed green throughout, because they only build English, which is the gap this workflow closes.