feat(ci): warm Next.js builds via Turbopack persistent cache on a sticky disk

[waleedlatif1]

Summary

• Enable Next 16's Turbopack persistent build cache (experimental.turbopackFileSystemCacheForBuild, beta) behind a NEXT_TURBOPACK_BUILD_CACHE env gate — only the CI check build opts in; production image builds keep the default cold path until the feature stabilizes
• Mount ./apps/sim/.next/cache as a Blacksmith sticky disk via the existing cache-mount action (same event/fork namespacing as the other mounts) — the Turbopack cache is ~5 GB, which sticky disks mount in ~1s while an actions/cache round-trip would eat the warm-build win; the GitHub-fallback path inside cache-mount still works
• Measured locally on this repo: 105s cold compile → 22s warm (4.8×). The Build App check is the merge gate (~3m40s, compile is ~80% of it), so this is direct merge-wait reduction; expect the effect from the second run onward as the disk warms
• Follow-up to fix(ci): save the Next.js build cache every run instead of freezing it at the lockfile key #5859 (which fixed the frozen actions/cache keying but revealed the cache carried almost nothing without the Turbopack flag)

Type of Change

• Improvement

Testing

Local A/B: cold build 105s (cache written, 4.8 GB), immediate rebuild 22.1s, byte-identical route table. This PR's own Build App run is cold (first sticky-disk fill); subsequent runs on the branch/staging show the warm number.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Jul 23, 2026 12:08am

[cursor]

PR Summary

Low Risk
CI and opt-in Next experimental build caching only; production builds are unchanged and there is no auth or data-path impact.

Overview
Speeds up the Build App merge gate by turning on Turbopack’s persistent build cache for that CI job only, and persisting the large .next/cache output on a sticky disk instead of actions/cache.

The Build App workflow now mounts ./apps/sim/.next/cache through the same cache-mount action as other caches (event/fork namespacing unchanged), replacing the per-run actions/cache restore that was costly for a ~5 GB Turbopack cache. The build step sets NEXT_TURBOPACK_BUILD_CACHE=1, which gates experimental.turbopackFileSystemCacheForBuild in next.config.ts. Production/image builds keep the default cold path because they do not set that env var.

^{Reviewed by Cursor Bugbot for commit 4790a49. Configure here.}

[greptile-apps]

Greptile Summary

This PR speeds up CI builds with Next.js Turbopack’s persistent filesystem cache. The main changes are:

• Mount the Next.js build cache on the existing provider-aware sticky disk.
• Enable the persistent Turbopack cache only for the CI build check.
• Keep production image builds on the default cold-build path.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
.github/workflows/test-build.yml	Moves the Next.js build cache to the shared cache-mount action and opts the CI build into persistent Turbopack caching.
apps/sim/next.config.ts	Adds an environment-controlled switch for Turbopack’s persistent build cache.

_{Reviews (2): Last reviewed commit: "chore(ci): drop the superseded actions/c..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ 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 4790a49. Configure here.}