Speed up preview deploys and CI: clone payloadcms-dev + cache seeded dev.db & Playwright

[rchlfryn]

Description

Bundle of CI/deploy speedups, plus consistency cleanups.

Stacked on #1059 (Next 16 upgrade). Will retarget to main after that merges.

Related Issues

N/A. Investigation came out of #1059's CI timing — the preview deploy run for that PR took 11 minutes, of which:

Step	Duration
Seed the database	3m 26s
Build Project Artifacts	2m 17s
Deploy to Vercel	2m 30s
Run database migrations	1m 35s
Other	~1m

Key Changes

1. Preview deploys clone payloadcms-dev instead of seeding from scratch

.github/workflows/preview.yaml:

• turso db create "${name}" --wait → turso db create "${name}" --from-db payloadcms-dev --wait. payloadcms-dev is already maintained by development.yaml and sync-prod-to-dev.yml — has all migrations applied and prod-derived data. Cloning is seconds.
• pnpm seed:standalone step removed entirely — clone has the data.
• pnpm migrate kept — idempotent. No-op when the PR doesn't add migrations; applies just the new ones when it does.

2. CI caches for the build & e2e jobs (was #1061, merged in)

.github/workflows/ci.yaml:

• Seeded dev.db cache (~3 min saved on hit). Cache key hashes seed scripts, migrations, payload config, collections, globals, and pnpm-lock.yaml. Applied to both build and e2e jobs (shared key, so they warm each other). Seed step skipped via if: steps.db-cache.outputs.cache-hit != 'true' on a hit.
• Playwright browser binaries cache (~30-60s saved on hit). Cache key includes pnpm-lock.yaml. We still call playwright install --with-deps so apt system deps stay in sync.

3. pnpm install --frozen-lockfile --ignore-workspace everywhere

Replaced pnpm ii (= pnpm --ignore-workspace install) across all 11 callsites in 6 workflow files: ci.yaml (×7), preview.yaml, development.yaml, production.yaml, dependabot-auto-format.yml, sync-prod-to-dev.yml. Frozen-lockfile skips lockfile reconciliation on CI and prevents accidental lockfile mutations from CI runs. Small per-job speedup, bigger consistency/safety win.

4. Drop Playwright webServer.timeout from 5 min → 90s

playwright.config.ts: was sized for slow webpack dev boots when E2E uses pnpm dev as its server. Next 16's default Turbopack dev boots in ~340ms (per #1059's tests), so 90s is plenty and we now fail fast when the server actually has trouble booting.

5. Cache .next/cache between preview deploys

vercel build runs next build underneath, which uses .next/cache for webpack/SWC module caches and ISR fetch cache. Caching that between preview runs lets subsequent deploys reuse incremental compilation state. Typical Next.js project savings on the build step are 30-60% when the cache hits.

Cache-key hierarchy:

• Primary: nextjs-cache-<os>-<lockfile-hash>-<sha> (per-commit, always saves fresh)
• Fallback 1: nextjs-cache-<os>-<lockfile-hash>- (most recent cache, same deps)
• Fallback 2: nextjs-cache-<os>- (any cache, e.g. when lockfile changes)

6. Shard E2E job by Playwright project (admin / frontend)

ci.yaml's e2e job now uses strategy.matrix to run admin and frontend specs on parallel runners via the existing test:e2e:admin / test:e2e:frontend scripts. Wall-clock for E2E is roughly halved on the test-execution side. fail-fast: false so a failure in one shard doesn't cancel the other.

Important: this changes the GitHub check-run names. The single e2e check becomes two checks: e2e (admin) and e2e (frontend). Branch protection / merge-queue required-status-checks need updating — remove e2e and add both e2e (admin) and e2e (frontend). (One-time settings change.)

Playwright report artifacts are also split: playwright-report-admin and playwright-report-frontend, since matrix jobs can't share the same artifact name.

Expected timing

Preview deploy: ~11m → ~5m

Step	Before	After
Create DB (now: clone)	~5s	~5s
Run migrations	1m 35s	~5s (no-op for most PRs)
Seed	3m 26s	removed
Build (warm .next/cache)	2m 17s	~1m to 1m 30s
Deploy	2m 30s	2m 30s

CI build & e2e jobs: ~3-4m saved on cache hit, plus E2E roughly halves with sharding.

How to test

• Open a no-op PR after this merges. Confirm preview deploys in ~5-6 min.
• Verify the deployed site has prod-derived content (real tenants/pages, not synthetic seed data).
• Open a PR that adds a migration; confirm pnpm migrate runs and applies it on the cloned DB.
• First preview build is cold (no .next/cache yet). Push a follow-up commit; the second build should be noticeably faster, and the GitHub Actions cache restore step should report a hit.
• Confirm build/e2e jobs in CI show the seed step as skipped after the cache is warmed.
• Confirm Playwright chromium download is fast on a second e2e run.
• Confirm e2e (admin) and e2e (frontend) both appear as separate checks in the merge queue.
• Update branch protection / required status checks to replace e2e with e2e (admin) + e2e (frontend).

Tradeoffs / risks

• Data exposure on previews: previews now contain real user accounts and prod-derived content — same as the existing payloadcms-dev deployment. Risk parity with dev.
• No more bootstrap@avy.com login: the seed creates that test user; cloning from dev/prod doesn't have it. Reviewers/QA log in with real prod accounts.
• Race window during dev refresh: development.yaml and sync-prod-to-dev.yml do destroy + create --from-db payloadcms-prod. A preview that lands in the ~5-second destroy/recreate window will fail at --from-db. Cost: rerun the workflow.
• Seed determinism (CI cache): assumes pnpm seed:standalone produces the same DB content for the same inputs. If hidden non-determinism (e.g. Date.now() in a field) causes flakes, the cleanest fix is making the seed deterministic; workaround is expanding the cache key.
• .next/cache correctness: the cache restoration is keyed by lockfile + commit SHA with restore-keys for fallback. If a stale cache somehow produces an incorrect build (Next/webpack bugs do happen), bumping the lockfile or running a no-op rebase forces a cold build. Cache size is bounded; GitHub keeps caches up to 10 GB and evicts LRU.
• E2E sharding doubles runner-minute cost (~2× the seat hours per E2E run) for ~50% wall-clock savings. Acceptable since E2E only runs on merge_group, not every PR push.
• Required-check rename: e2e → e2e (admin) + e2e (frontend). Merges may stall until branch protection settings are updated.

Migration Explanation

No application database migrations. CI/deploy-only change.

Future enhancements

• Bigger CI runners (runs-on: ubuntu-latest-4-cores) — would shrink the build job especially. Cost: more GitHub Actions minutes.
• Composite action for the setup repo + pnpm + node + install boilerplate (duplicated 11+ times). Pure refactor, no perf change.

🤖 Generated with Claude Code

[github-actions]

Preview deployment: https://chorexpreview-deploy-speedup.preview.avy-fx.org

[rchlfryn]

Closing because we don't need to spend time on this at the moment