Uh oh!
There was an error while loading. Please reload this page.
fix(ci): unblock @next/swc, lockfile-keyed node_modules, per-image runner sizing - #5945
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview Sticky Docker image build matrices gain Reviewed by Cursor Bugbot for commit 5a43163. Configure here. |
Greptile SummaryThis PR improves CI dependency correctness, cache isolation, runner sizing, and build diagnostics.
Confidence Score: 5/5The PR appears safe to merge, with the previously reported GitHub fallback failure corrected by making the memory check warning-only. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| .github/workflows/test-build.yml | Isolates dependency volumes by lockfile and safely changes the runner-memory preflight from a hard gate to a diagnostic warning. |
| .github/workflows/ci.yml | Moves Blacksmith runner selection into each Docker matrix entry to support per-image sizing. |
| .github/workflows/docs-embeddings.yml | Reduces the runner allocated to the network-bound documentation embeddings job. |
| package.json | Declares pinned platform-specific SWC binaries as root optional dependencies. |
| bun.lock | Records all four platform-specific SWC packages with their operating-system and CPU constraints. |
| bunfig.toml | Exempts the pinned SWC binaries from the temporary minimum-release-age gate alongside Next.js. |
Reviews (5): Last reviewed commit: "docs(ci): explain ARM runner sizing rati..." | Re-trigger Greptile
8fbc662 to
a86b189Comparewaleedlatif1
commented
Jul 24, 2026
waleedlatif1
commented
Jul 24, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit a86b189. Configure here.
waleedlatif1
commented
Jul 24, 2026
waleedlatif1
commented
Jul 24, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
waleedlatif1
commented
Jul 24, 2026
waleedlatif1
commented
Jul 24, 2026
@cursor review |
waleedlatif1
commented
Jul 24, 2026
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 2efc5ed. Configure here.
waleedlatif1
commented
Jul 24, 2026
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 5a43163. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
16.2.12 is the current stable (published 2026-07-25) and its entire changelog is two PRs: a docs backport and vercel/next.js#95831, "Fixes to support TypeScript 7". That second one matters here. `apps/sim` declares `typescript: ^7.0.2` and the lockfile resolves 7.0.2, while 16.2.11 predates any TS7 handling — not even the actionable-error guard (#95837), which was never merged. The upstream symptom is `next build` dying with a silent SIGSEGV during its type-check step, because the legacy TypeScript JS API that Next called is gone in TS7. Builds pass today only because Next detects @typescript/native-preview as the compiler and takes a different path, so we are accidentally-working rather than supported. 16.2.12 adds the `experimental.useTypeScriptCli` backend that makes this configuration official. Zero build-performance content in the patch, so this is not a speed change. Bumps all eight pins in lockstep — next, @next/env and the four @next/swc-* binaries at the root, plus the three app/package copies. The swc binaries must move with next: they are platform-gated optionalDependencies, so a version skew or a gate exclusion leaves them out of bun.lock entirely and `bun install --frozen-lockfile` installs no compiler at all (the #5945 failure). Also re-dates the bunfig.toml gate note, which said to drop the next entries on 2026-07-28 — yesterday. 16.2.12 is inside the 7-day window until 2026-08-01, so following that instruction would have blocked this bump and re-triggered the missing-compiler failure. Re-date on future bumps rather than deleting the entries early.
Summary
Three CI fixes, all traced to real telemetry rather than guesswork.
1. The
@next/swc-*binaries were blocked by the supply-chain age gateEvery Build App run logged:
16.2.6appears nowhere inbun.lockor anypackage.json, so CI was compiling production bundles with an SWC binary the lockfile does not reference.Root cause: #5890 bumped next
16.2.6→16.2.11for the July 2026 security advisories and addednext+@next/envtominimumReleaseAgeExcludesso they could install — but not the@next/swc-*platform binaries, which ship in lockstep withnextand were published the same day. They stayed blocked by the 7-day gate, sobun installhas been silently installing no compiler at all since that bump (they are optional deps, so the failure is silent). Reproduced directly: adding@next/swc-linux-x64-gnu@16.2.11erroredpublished within minimum release age of 604800 seconds; with the exclude added it resolves.Fix, in two parts (the first alone is not enough — verified by a CI run that still tried to download the compiler):
@next/swc-*binaries tominimumReleaseAgeExcludes, alongside thenextentry that should have carried them.optionalDependenciesso they get resolved entries inbun.lock. Without an entry,bun install --frozen-lockfilecannot install a package at all — next's inline optional-dependency metadata is not sufficient. Each package carriesos/cpuconstraints, so only the matching one installs per platform; the lockfile records all four.1b.
node_modulessticky disk was shared across branchesThe disk was keyed only on
github.event_name, so every branch shared one mutablenode_modulesvolume. A sticky disk is a persistent mutable volume, not a content-addressed cache, andbun install --frozen-lockfileadds what the lockfile needs without pruning what it dropped — so the pre-bump16.2.6binary survived on the shared disk and was served to every16.2.11build. That is why the missing-compiler bug above stayed hidden: the stale disk was masking it.Fix: add the
bun.lockhash to that key. The bun download cache and Turbo cache are content/hash-addressed and stay shared, which keeps a freshnode_modulesdisk cheap to fill.Note these two are coupled: fixing the cache key alone gives a clean disk with no SWC binary, at which point next tries to download one at build time and dies on registry detection. Both fixes are required together.
2. Per-image Blacksmith runner sizing (
bs_runner)All three Docker matrices pinned every image to 8 vCPU on Blacksmith, even though the existing
gh_runnercolumn already documents that only the app image needs a big runner. The non-app builds idle at 12–15% CPU and under 10% memory. Added abs_runnerfield mirroringgh_runnerso the sizing lives with the image and can't drift back: app 8 vCPU, migrations 2, realtime 4, PII 4 (same for ARM). Also dropped docs-embeddings 8 → 2 vCPU — it's network-bound on the embeddings API at ~9% CPU.3. Cold-build memory warning
Running out of RAM kills the whole VM and surfaces only as
The runner has received a shutdown signal— no mention of memory, after ~12 minutes of work. That's what made the OOM fixed in #5944 hard to diagnose. The build job now reportsMemTotalup front and emits a::warning::with the real numbers when the runner is under 40 GB. Warning-only on purpose: warm builds peak ~12 GB and partial ~28 GB, so a 32 GB runner still completes many builds, and hard-failing them would degrade the break-glass GitHub path rather than protect it.This also addresses the P1 left open on #5944: the GitHub fallback (
linux-x64-8-core, 32 GB) is still below the ~51 GB cold peak. Rather than guess a larger label —hosted-runnersreportstotal_count: 0for the org, so no GitHub larger runners appear provisioned, and an unresolvableruns-onlabel queues forever — the preflight turns that path into an immediate, explanatory failure on any provider.Not included:
.next/cacheThe ~5 GB Turbopack FS cache shares the same event+fork key, but keying it on the lockfile would be redundant:
NEXT_TURBOPACK_BUILD_CACHEalready hashes on config/deps/module content, so a lockfile bump invalidates those slices on its own. The way that cache could be corrupted was a mismatched compiler writing entries into it — which fix 1 removes at the source.Type of Change
Testing
Tested manually — all three workflows parse; preflight verified under
bash -n; every matrix referencingbs_runnerdefines it on all 12 entries.Checklist