Skip to content

ci: boot docs + ui-website in the In-repo app tests job #627

Description

@vivek7405

Problem

The apps CI job ("In-repo app tests (website + blog)", .github/workflows/ci.yml ~L264-292) boots only the website and blog (it runs each app's own webjs test). Its own comment (L272-273) states docs and packages/ui/packages/website (ui-website) are excluded because they ship no test suite. webjs check runs on all four (L35), but that is convention validation, not a boot/SSR check.

So a regression that breaks docs or ui-website SSR (a bad importmap, a server-only import leaking to the client, a render throw) passes CI. Today that gap is covered by a MANUAL discipline (boot all four dogfood apps every framework PR), which is fragile because it relies on the agent remembering. Automate it.

Design / approach

Add a boot smoke for docs + ui-website to the apps job. They have no webjs test suite, so use the in-process boot the other dogfood checks use: createRequestHandler({ appDir, dev: false }) from @webjsdev/server, drive a GET on a known route via the handle() harness, and assert status < 400 (and ideally that the served <script type=\"importmap\"> is present for a browser-wire smoke). Run in dist mode where applicable so it covers the prod wire. Keep it lightweight (one or two routes per app), not a full suite.

Implementation notes (for the implementing agent)

  • Where to edit: .github/workflows/ci.yml, the apps job (~L264-292). Add steps that boot docs (docs/) and ui-website (packages/ui/packages/website/). Update the job comment at L272-273 (it currently justifies their exclusion) and consider renaming the job from "(website + blog)" to "(all in-repo apps)".
  • Boot pattern: createRequestHandler({ appDir, dev: false }) + handle('GET', '<route>'), assert status < 400. The harness must run from INSIDE the repo (bare @webjsdev/* only resolves from the repo node_modules). A small script under test/ or a scripts/ boot-smoke is cleaner than inline YAML.
  • Landmines: docs needs its Tailwind built (npm run css:build / the webjs.start.before step) before serving, and ui-website may need its registry built; reproduce each app's start prerequisites or the boot 500s on a missing asset. ui-website currently has a pre-existing no-static-properties violation in its vendored components/ui/* (the in-progress Deprecate static properties field and enforce declare-free factory DX #598 migration) but that does not affect SSR boot.
  • Invariants: keep packages/ buildless (no new build step for the framework); the smoke is CI-only tooling.
  • Tests + docs: this IS test/CI infra (no app-runtime change). Update the apps job comment; no docs-site or AGENTS.md change needed.

Acceptance criteria

  • CI boots all four in-repo apps (blog, website, docs, ui-website) and asserts each serves (status < 400)
  • A regression that only breaks docs or ui-website SSR fails CI with no manual boot
  • The apps job comment no longer claims docs / ui-website are uncovered
  • The manual "boot all 4 dogfood apps every PR" discipline becomes a backstop, not the primary coverage

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

Status
Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions