Fix benchmark dashboard HTML exceeding GitHub's 100 MB push limit

[Copilot]

The "Build benchmark history dashboard" CI job was failing because benchmark-history.html grew to 156 MB — over GitHub's 100 MB file size limit. The root cause: createBenchmarkHistoryDashboard embedded all historical runs in the inline JSON blob, growing unboundedly, even though the chart already capped rendered points at DASHBOARD_RUN_LIMIT (100).

Changes

• scripts/benchmark/benchmark-history.ts: Slice embedded runs to DASHBOARD_RUN_LIMIT before serializing into the HTML. Capture the pre-slice count as totalRunCount so the "stored runs" header stat remains accurate.

// Before — all runs embedded
const data = JSON.stringify({ runs, points, dashboardRunLimit })

// After — only the most recent DASHBOARD_RUN_LIMIT runs embedded
const totalRunCount = runs.length
const dashboardRuns = runs.slice(-DASHBOARD_RUN_LIMIT)
const data = JSON.stringify({ runs: dashboardRuns, totalRunCount, points, dashboardRunLimit })

• Template JS: Use dashboardData.totalRunCount ?? dashboardData.runs.length for the "stored runs" display so the header reflects the true historical total, not just the capped window.

• tests/benchmark-history.test.ts: Update assertions for the 101-run fixture — runs in the payload is now capped at 100, and totalRunCount carries the true count of 101.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
capacity-node-autorouter	Ready	Preview, Comment	Jul 28, 2026 10:57am

[0hmX]

@copilot any other solution? like use large files storage ?

[Copilot]

@copilot any other solution? like use large files storage ?

LFS isn't a good fit here for two reasons:

1. GitHub Pages doesn't serve LFS files — it would just render the pointer file, breaking the dashboard website entirely.
2. LFS has bandwidth/storage limits — the free tier is 1 GB/month bandwidth, so frequent CI pushes + page views could exhaust the quota quickly and cost money.

The current fix (slicing runs to DASHBOARD_RUN_LIMIT before embedding) is a better approach because the chart already only renders 100 runs anyway, so there's no information loss for users. The "stored runs" header still shows the true historical total via totalRunCount. The HTML will stay well under 100 MB going forward regardless of how many runs accumulate.