* ci: serialise image builds and stop the API-pages workflow clobbering the lockfile
build_n_push: add a per-ref concurrency group so two quick merges to main can't race the :main tag (last push wins regardless of commit order, and the server auto-pulls :main); add permissions: contents: read; validate .dockerignore and package.json changes in the PR path filter.
generate_api_pages: pin Node 20 and switch npm install -> npm ci so the run can never rewrite the now-tracked package-lock.json with a divergent macOS-resolved tree; stage only src/pages/ipa/resources instead of git add -A; drop --force from the push — a force-push from this workflow would silently rewrite main and destroy any PR merged since its checkout.
* chore: warn when per-page dates are skipped; drop dead per-file git lookup
buildGitDateMap now logs a warning when it emits no dates (git missing or shallow clone) instead of silently blanking every page's Updated line and the sitemap lastmod entries; document the squash-merge assumption behind the --name-only walk. Remove the unused getGitLastModified. Note in CLAUDE.md that npm run start warns under output: 'standalone'. Gen output verified byte-identical.
* ci: self-heal the API-pages push when main moves mid-run
Rebase the single generated-files commit onto the moved branch before pushing, so a PR merged during the multi-minute run no longer rejects the push (the failure --force was presumably papering over). A genuine conflict — a concurrent edit of the generated files themselves — still fails the run loudly with main untouched. Also serialise dispatches with a concurrency group: run history shows several same-day dispatches, and overlapping runs regenerate the same files.
Sandbox-tested against a bare repo: plain push rejected on race; rebase+push lands with both commits intact; true conflict exits 1 leaving the branch tip untouched.
* ci: sync to branch tip before regenerating API pages
A run queued behind another checks out the commit pinned at its dispatch time; regenerating against that stale base means the pre-push rebase replays a snapshot diff, and a file the newer spec removed can silently survive from the prior run. Fetch + reset to the branch tip before generating so the diff is computed against reality. Also note the latest-dispatched-vs-newest-tag caveat on the concurrency comment.
Sandbox-proven: with the old order a removed-in-newer-spec file survives the rebase replay; with sync-first it is gone.
* Prevent stale workflows from overwriting newer published content
* Coderabbit Fix
---------
Co-authored-by: Brandon Hopkins <brandon@techhut.tv>
Move `npm run build` out of the Docker image onto the runner, where actions/cache persists .next/cache across runs (the in-Docker build discarded it every time). The image now just packages the prebuilt .next and serves it with `next start`; runtime and the DocSearch entrypoint injection are unchanged.
Also: checkout full history (fetch-depth: 0) so per-page dates are correct, guard buildGitDateMap against shallow clones (correct-or-absent, never wrong), modernise the Docker actions (build-push-action v6, provenance: false), and add a path-filtered pull_request trigger so pipeline changes are validated before merge.
Smoke-tested via isolated build + docker run: serves /, /introduction, /api, sitemap, static assets (200); DocSearch placeholder injection intact.
Replace ~314 `git log` spawns per gen script with a single `git log --name-only` pass, memoised per process. Cuts gen:last-updated + gen:sitemap from ~15s to ~1.5s.
Output is byte-identical to the per-file version; still degrades to no-dates when git is unavailable (e.g. the Docker image).
