Shallow-clone preview builds to fix checkout variance.#1458
Shallow-clone preview builds to fix checkout variance.#1458nathenharvey wants to merge 7 commits into
Conversation
Process control analysis across 83 PR Preview runs identified the Checkout step as the dominant source of variance in `build_drafts_on` (σ=16.5s vs σ=2.5s for `build_drafts_off`). Two recent runs hit 73s runs outside XmR control limits. The root cause is that actions/checkout fetches the full commit history by default. The build needs only the working tree at HEAD — no git history is required by Hugo, Svelte, or the Firebase deploy. With fetch-depth: 1, only the tip commit is fetched regardless of repo depth. Without this change, checkout time will continue to grow as the repo accumulates commits, and the outlier pattern will worsen. Expected outcome: checkout normalizes to 2–5s, σ drops below 3s for both jobs, and mean build time falls by ~10–12s (~15%). Only the two build jobs are changed. The test and test_redirects jobs retain their existing checkout config (one uses submodules: recursive and a different action version).
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Visit the preview URL for this PR (updated for commit 0345fa1): https://doradotdev--pr1458-drafts-off-6i7ovnpv.web.app (expires Wed, 22 Jul 2026 17:10:32 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 7ad2b3cf9cceb558b493931176f998ae46924361 |
|
After 10 builds, |
Process control analysis identified the Svelte build step as the second-largest source of variance in preview build times (mean ~9s, σ=4.4s, with cold-start spikes to 32s). The full `npm ci` runs on every preview build even when `package-lock.json` hasn't changed, which means re-downloading and re-installing the same packages on every PR. `actions/cache@v4` now restores `svelte/node_modules` before the build step, keyed on the workspace `package-lock.json` hash. When the cache hits, `build.sh` skips `npm ci` entirely and the four Svelte subprojects go straight to vite build. Cache invalidates automatically on any lockfile change. Expected outcome: Svelte build step drops from ~9s to ~1-2s on cache hits, cold-start spikes are eliminated, and the cache miss path is identical to the current baseline. `deploy.yml` is intentionally unchanged — it always runs `npm ci`, which remains correct for production deployments.
|
Caching svelte builds delivers ~2s savings (eliminating npm ci) and elimination of the cold-start spike pattern. The mean dropped from ~8.9s → ~6.9s, σ improved from 2.9s → 1.9s. Modest but real. To get to 1–2s, the Vite builds themselves would need to be cached — specifically the dist/ outputs, keyed on source file hashes. That's a larger change with higher staleness risk, and is probably not worth pursuing unless the Svelte code changes infrequently relative to build frequency. The PR is worth merging for the spike elimination alone, there is a modest (~2s) performance gain. |
Explicitly set up Node.js by adding the `setup-node` action with caching before the Svelte step to eliminate overhead
Switching to `npm ci` enforces a clean, deterministic installation based strictly on your lockfile. This is significantly faster and more reliable in CI environments.
These changes didn't have a significant impact on build times and introduce additional complexity. Let's remove them.
nathenharvey
force-pushed
the
push-ttnqonkwkkyp
branch
from
9e3c008 to
a2e8a07
Compare
Explicitly set up Node.js by adding the `setup-node` action with caching before the Svelte step to eliminate overhead
Cache the `svelte/node_modules` directory in the preview workflow to reduce CI execution times. - Adds `actions/cache@v4` steps in `.github/workflows/preview.yml` keyed by the hash of `svelte/package-lock.json`. - Updates `svelte/build.sh` to skip running `npm ci` if `svelte/node_modules` is already present (e.g., when successfully restored from the cache).
1 participant
Process control analysis across 83 PR Preview runs identified the Checkout step as the dominant source of variance in
build_drafts_on(σ=16.5s vs σ=2.5s forbuild_drafts_off). Two recent runs hit 73s runs outside XmR control limits.The root cause is that actions/checkout fetches the full commit history by default. The build needs only the working tree at HEAD — no git history is required by Hugo, Svelte, or the Firebase deploy. With fetch-depth: 1, only the tip commit is fetched regardless of repo depth.
Without this change, checkout time will continue to grow as the repo accumulates commits, and the outlier pattern will worsen.
Expected outcome: checkout normalizes to 2–5s, σ drops below 3s for both jobs, and mean build time falls by ~10–12s (~15%).
Only the two build jobs are changed. The test and test_redirects jobs retain their existing checkout config (one uses submodules: recursive and a different action version).