fix(ci): scope the Next.js build cache sticky disk per branch

The Turbopack persistent build cache disk was keyed on github.event_name
alone, so every open PR shared one mutable volume. A sticky disk mount
clones the last committed snapshot and commits back last-write-wins, so
each PR build restored a cache produced by a different branch.

Measured on the same staging commit, two runs minutes apart: the
single-writer push disk compiled in 9.3 min, the shared pull_request
disk in 14.0 min. Across 22 recent runs, push builds land at 3.5-11 min
and PR builds at 13.5-17.8 min.

Correctness matters more than the minutes here.
turbopackFileSystemCacheForBuild is beta and cross-commit restore is not
a documented-supported mode - vercel/next.js#87283 reports stale HTML
from a cache built at another commit, with no maintainer answer. Every
other cache layer in this repo already isolates by branch: GitHub's
cache cannot read sibling branches, and Blacksmith's cache product
branch-scopes by default. Only this key didn't.

Adds pre/post-build cache size reporting, because whether the cache was
warm is otherwise invisible - the disk mounts either way and turbo
buffers the build log. Adds ci-cache-cleanup.yml to delete a branch's
disk when its PR closes, so per-branch disks track open PRs instead of
accumulating at ~5 GB each.

Also corrects the 105s-cold/22s-warm comment: those were local numbers
and have never reproduced in CI.

Author: waleedlatif1

.github/workflows/ci-cache-cleanup.yml

@@ -0,0 +1,38 @@
+name: CI Cache Cleanup
+
+# The Next.js build cache sticky disk in test-build.yml is keyed per branch, so
+# every PR leaves a ~5 GB volume behind. Branches are short-lived; the disks
+# aren't. Delete a branch's disk when its PR closes so storage tracks open PRs
+# rather than every branch the repo has ever seen.
+#
+# Only the pull_request-event disk is deleted. The push-event disks belong to
+# main/staging/dev and must stay warm.
+
+on:
+  pull_request:
+    types: [closed]
+
+concurrency:
+  group: ci-cache-cleanup-${{ github.head_ref }}
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  delete-nextjs-cache:
+    name: Delete Next.js build cache disk
+    # Sticky disks only exist on Blacksmith; in GitHub break-glass mode the
+    # cache-mount fallback uses actions/cache, which expires on its own.
+    if: vars.CI_PROVIDER == '' || vars.CI_PROVIDER == 'blacksmith'
+    runs-on: blacksmith-2vcpu-ubuntu-2404
+    timeout-minutes: 5
+
+    steps:
+      # Key must stay byte-identical to the Mount Next.js build cache key in
+      # test-build.yml, or this silently deletes nothing and the disks pile up.
+      - name: Delete sticky disk
+        uses: useblacksmith/stickydisk-delete@b41313d28b8647d72114c9ba3c96bb04061562b6 # v1
+        continue-on-error: true
+        with:
+          delete-key: ${{ github.repository }}-nextjs-cache-pull_request${{ github.event.pull_request.head.repo.fork && '-fork' || '' }}-${{ github.head_ref }}

.github/workflows/test-build.yml

@@ -265,14 +265,31 @@ jobs:
 
       # Turbopack's persistent build cache (NEXT_TURBOPACK_BUILD_CACHE below)
       # writes ~5 GB into .next/cache — a sticky disk mounts it in ~1s where an
-      # actions/cache round-trip would eat the warm-build win. Same event/fork
-      # namespacing as the other mounts; the GitHub fallback inside cache-mount
-      # still uses actions/cache with a run_id-suffixed key.
+      # actions/cache round-trip would eat the warm-build win.
+      #
+      # Scoped per branch, not just per event. A sticky disk is a single mutable
+      # volume per key: mounting clones the last committed snapshot and the job
+      # commits back last-write-wins. Keyed on event alone, every open PR shared
+      # one volume, so each run cloned a snapshot built from a *different*
+      # branch. Measured on the same staging commit, minutes apart: the push
+      # disk (single-writer, genuinely warm) compiled in 9.3 min while the
+      # shared pull_request disk took 14.0 min.
+      #
+      # Branch scoping is also the correctness-preserving choice —
+      # turbopackFileSystemCacheForBuild is beta, and cross-commit restore is
+      # not a documented-supported mode (vercel/next.js#87283 reports stale HTML
+      # from a cache built at another commit). Every other cache layer here
+      # already isolates by branch: GitHub's cache can't read sibling branches,
+      # and Blacksmith's own cache product branch-scopes by default. Only this
+      # key didn't.
+      #
+      # Cost of per-branch disks is bounded by ci-cache-cleanup.yml, which
+      # deletes a branch's disk when its PR closes.
       - name: Mount Next.js build cache
         uses: ./.github/actions/cache-mount
         with:
           provider: ${{ vars.CI_PROVIDER }}
-          key: ${{ github.repository }}-nextjs-cache-${{ github.event_name }}${{ github.event.pull_request.head.repo.fork && '-fork' || '' }}
+          key: ${{ github.repository }}-nextjs-cache-${{ github.event_name }}${{ github.event.pull_request.head.repo.fork && '-fork' || '' }}-${{ github.head_ref || github.ref_name }}
           path: ./apps/sim/.next/cache
 
       # Running out of RAM kills the whole VM and surfaces only as "the runner
@@ -293,6 +310,20 @@ jobs:
       - name: Install dependencies
         run: bun install --frozen-lockfile --ignore-scripts
 
+      # Whether the Turbopack cache was warm is otherwise invisible: the disk
+      # mounts successfully either way, and turbo buffers the build log so
+      # compile time only surfaces at the end. Without this, "is the cache
+      # working" can only be answered by diffing compile times across runs and
+      # guessing. Reported, never gated — this is a measurement, not a check.
+      - name: Report Next.js cache state (pre-build)
+        run: |
+          CACHE_DIR=apps/sim/.next/cache
+          if [ -d "$CACHE_DIR" ] && [ -n "$(ls -A "$CACHE_DIR" 2>/dev/null)" ]; then
+            echo "PRE_BUILD_CACHE=warm ($(du -sh "$CACHE_DIR" | cut -f1), $(find "$CACHE_DIR" -type f | wc -l) files)"
+          else
+            echo 'PRE_BUILD_CACHE=cold (empty or absent — expect a full compile)'
+          fi
+
       - name: Build application
         env:
           NODE_OPTIONS: '--no-warnings --max-old-space-size=8192'
@@ -304,7 +335,19 @@ jobs:
           AWS_REGION: 'us-west-2'
           ENCRYPTION_KEY: '7cf672e460e430c1fba707575c2b0e2ad5a99dddf9b7b7e3b5646e630861db1c' # dummy key for CI only
           TURBO_CACHE_DIR: .turbo
-          # Opt into Turbopack's persistent build cache (beta) for this CI
-          # check build only — measured 105s cold vs 22s warm locally.
+          # Opt into Turbopack's persistent build cache (beta) for this CI check
+          # build only. The 105s-cold/22s-warm figures behind this were measured
+          # locally and have never reproduced in CI, where compile has ranged
+          # 3.5-17.8 min — treat them as local numbers, not a CI target.
           NEXT_TURBOPACK_BUILD_CACHE: '1'
         run: bunx turbo run build --filter=sim
+
+      - name: Report Next.js cache state (post-build)
+        if: always()
+        run: |
+          CACHE_DIR=apps/sim/.next/cache
+          if [ -d "$CACHE_DIR" ]; then
+            echo "POST_BUILD_CACHE=$(du -sh "$CACHE_DIR" | cut -f1) committed to the sticky disk for the next run on this branch"
+          else
+            echo 'POST_BUILD_CACHE=absent — the build wrote no cache'
+          fi