Skip to content

CI's UI build step doesn't reproduce Cloudflare Pages' actual build invocation #6642

Description

@JSONbored

Context

PR #6624 fixed a real production incident: the Cloudflare Pages project for loopover-ui has its root directory set to apps/loopover-ui, so Cloudflare's automatic npm clean-install step only installs that workspace's own declared dependencies (957 packages), never reaching sibling workspace packages. This silently worked until packages/loopover-engine gained two new direct dependencies (@anthropic-ai/claude-agent-sdk, web-tree-sitter), at which point every PR touching apps/loopover-ui/** started failing the Workers Builds: loopover-ui check with TS2307: Cannot find module.

The fix (already merged) made apps/loopover-ui/package.json's build:cloudflare script self-sufficient (npm --prefix ../.. ci && npm --prefix ../.. run ui:build), so it no longer depends on Cloudflare's own root-scoped install being complete.

The gap

.github/workflows/ci.yml's "UI build" step (around line 470) runs:

npm run extension:build && npm run miner-extension:build && npm --workspace @loopover/ui run build

This invokes the app's plain build script (vite build) directly from a full monorepo-root npm ci context — it never runs build:cloudflare, and never simulates a root-directory-scoped install the way the actual Cloudflare Pages build does. So a regression of the exact class #6624 fixed (a new dependency landing in packages/loopover-engine — or any other sibling workspace apps/loopover-ui transitively depends on — without being independently installable from apps/loopover-ui's own scope) would pass CI's "UI build" check cleanly and only surface once Cloudflare's own native build ran on the PR, same as this incident.

Requirements

  • Add a CI check (in ci.yml or a dedicated job) that exercises apps/loopover-ui's build:cloudflare script specifically, from a working directory scoped to apps/loopover-ui — not the monorepo-root ui:build aggregate — so a future dependency-resolution gap in that build path is caught before merge, not after a live Cloudflare build failure.
  • The check must fail the PR (not just warn) when build:cloudflare fails, mirroring how validate-tests/ui:build already gate merges today.
  • Document (a short comment near the new step, matching this repo's existing comment density) why this step exists and what incident it guards against, so a future refactor doesn't quietly remove it as "redundant" with the existing ui:build step.

Non-goals

  • Changing the Cloudflare Pages project's dashboard settings (root directory) — that's an external configuration this repo's CI can't control or verify directly; the fix is making the build path itself resilient and CI-verified regardless of what Cloudflare's own install step covers.
  • Auditing apps/loopover-miner-ui, apps/loopover-extension, or apps/loopover-miner-extension for the same risk — already checked; none of them has its own wrangler.jsonc/Cloudflare Pages project or a root-directory-scoped build script, so they aren't exposed to this class of bug.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions