ci: add PR-time next build validation (#45)#49
Conversation
Catches build-only failures pre-merge so they don't blow up at production-deploy time the way #44 (middleware/proxy file-name conflict), #47 (proxy host check), and #48 (env-conflated indexable-host derivation) all did. Triggers on pull_request to main, with a path filter so PRs that only touch docs / WP plugin / WP theme don't pay the build cost. File globs cover anything that affects the next build: - source: app/, components/, lib/, src/, css/, fonts/, messages/ - public assets: public/ - middleware/proxy entry points: proxy.ts, middleware.ts - configs: next.config.*, tsconfig*, tailwind.config.*, postcss.config.*, .nvmrc - dependencies: package.json, package-lock.json - the workflow itself Concurrency group pr-build-<PR-number> with cancel-in-progress so new commits on a PR cancel earlier in-flight builds. Caches .next/cache keyed on package-lock.json (with TS/CSS hash as secondary key) for cold-build speed. Builds with the same env vars production uses so the same code path is exercised. NEXT_PUBLIC_SITE_URL_PROD is fine for the PR build — we just need a valid URL; the artifact is thrown away. Implements #45. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 28 minutes and 14 seconds.Comment |
Up to standards ✅🟢 Issues
|
…ible) GitHub Actions' \`paths\` filter at the trigger level skips the workflow entirely when no matching files change. If this workflow is marked as a required check on main, PRs that touch only docs / WP plugin / WP theme would have a never-reported status — which the required-check rule treats as missing → blocks merge indefinitely. Always-run + .next/cache is the simpler shape. Cached builds run in ~1–2 min, which is fine on every PR. Worth it to make the required check actually function. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Closes #45. Adds
.github/workflows/pr-build.ymlthat runsnext buildon PRs that touch Next.js build inputs, so build-onlyfailures are caught pre-merge instead of at production-deploy time.
Why now
Three recent production breaks in this PR series would have been
caught by this workflow:
middleware.tsandproxy.tsboth present (Next.js 16 conflict)request.nextUrl.hostnamereturned localhost on prod (trustHostHeader: false)NEXT_PUBLIC_SITE_URLwith indexable-host setThe middleware/proxy conflict is exactly the class this PR
prevents: the build fails with a clear error if the conflict is
in the diff, before the broken code ever gets onto main.
How
pull_requestagainstmainnext buildchange(source, configs, deps, public assets, the workflow itself)
WP_GRAPHQL_URL,NEXT_PUBLIC_SITE_URL) so the build exercises the same code path.next/cachekeyed onpackage-lock.jsonfor cold-build speed
Acceptance criteria from #45
.next/cacherepo settings change after this lands)
we have one in-flight; not worth manufacturing)
Out of scope
🤖 Generated with Claude Code