mirror of
https://github.com/simstudioai/sim.git
synced 2026-09-24 15:45:35 +08:00
Waleed
3e62546e50
* perf(ci): disable the Turbopack persistent build cache It is a net loss at this app's size. A controlled A/B on one branch (#6078), three runs with a byte-identical module graph so only cache state varied: cache OFF 113s compile, 2m53s job cache ON, cold 162s compile, 3m54s job cache ON, warm 360s compile, 8m18s job The cache made the same build 3.2x slower. It also grew 5.1 GB -> 12 GB across two runs of an unchanged tree, which explains the progressive degradation seen on longer-lived disks (up to 11.7 min): the more a disk is written, the more the next run must read and revalidate. Flag manipulation is visible in the logs — the cache-on runs print `✓ turbopackFileSystemCacheForBuild`, the cache-off run omits it — and every run used `turbo --force` so none is a replayed log. #5869 enabled this on locally-measured numbers (105s cold -> 22s warm) that never reproduced in CI and are inverted here. #6072 then branch-scoped the disk to stop PRs restoring each other's caches; that fixed a real problem, but with the cache off the disk is unnecessary, so the mount, the pre/post size reporting, and the env gate all go with it. Pins `turbopackFileSystemCacheForBuild: false` explicitly rather than relying on the Next default: upstream already flips that default to true in canary/preview builds (vercel/next.js#94616), so leaning on the default would let a version bump silently re-enable this. Keeps ci-cache-cleanup.yml, re-scoped to draining the 5-12 GB volumes that PRs opened while the per-branch key was live still hold — nothing else reclaims them. It is a no-op for new PRs and can be deleted once drained. Caveat: n=1 per cell. The 3.2x effect size and agreement with ~15 prior observations make it convincing, but this is three runs, not a distribution. * docs(ci): correct the cleanup key comment after the mount was removed Greptile P2: the delete step still claimed its key must stay byte-identical to the Mount Next.js build cache step in test-build.yml, but this PR removes that mount. It is now a hard-coded legacy drain key that mirrors nothing.
40 lines
1.7 KiB
YAML
40 lines
1.7 KiB
YAML
name: CI Cache Cleanup
|
|
|
|
# DRAINING LEGACY DISKS ONLY. test-build.yml no longer mounts a Next.js build
|
|
# cache — the Turbopack persistent cache measured 3.2x SLOWER than no cache, so it
|
|
# is off. But every PR open while the per-branch key was live left a 5-12 GB volume
|
|
# behind, and nothing else reclaims them. This keeps deleting them as those PRs
|
|
# close.
|
|
#
|
|
# Delete this workflow once the backlog is drained (no PR predating the cache
|
|
# removal is still open). It is a no-op for new PRs, which never create a disk.
|
|
|
|
on:
|
|
pull_request:
|
|
types: [closed]
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
jobs:
|
|
delete-nextjs-cache:
|
|
name: Delete Next.js build cache disk
|
|
# Sticky disks only exist on Blacksmith; the GitHub break-glass path 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:
|
|
# A hard-coded legacy drain key. It no longer mirrors anything — the
|
|
# Mount Next.js build cache step it used to match was removed with the
|
|
# cache. Do not retarget or delete it while PRs from before that removal
|
|
# are still open, or their 5-12 GB disks are never reclaimed.
|
|
# Non-blocking: PRs skipped by ci.yml's paths-ignore never made a disk,
|
|
# and neither does any PR opened after the removal.
|
|
- 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 }}
|