Add dogfood-viewer.mjs: use the product to visually regression-test itself - #89
Merged
Conversation
…tself Prompted by "how could we take our own product into use in e2e" -- picked the persistent-instance option over the two cheaper ones (a throwaway smoke test, or committing baseline PNGs to this repo), since the author is separately standing up a real hosted instance to point this at, closing the loop completely: review happens through the real viewer, the same as any other snapshot. Fundamentally different lifecycle from e2e.test.ts's fully ephemeral, self-contained backend (spawned and torn down within one vitest run): this script targets a real, long-lived instance via PPS_SERVER_URL / PPS_VIEWER_URL (PPS_API_TOKEN optional) -- the same env var convention packages/client already establishes -- and never auto-approves. A handful of the viewer's own key pages (run list, run detail, snapshot detail dual/single, Settings, Branches & Releases) get captured with the real client library and uploaded as ordinary snapshots, under fixed names so repeated runs diff against whatever was previously approved -- there's nothing dogfood-specific about the diffing itself, it's the same mechanism as any other use of the product. Each run also seeds a small amount of fresh demo data (a passing baseline plus a genuine regression against it) so there's always something real for the captured pages to render, even against a brand-new instance. The point: a genuine layout regression in the viewer itself -- the kind this project has so far only ever caught by hand, via one-off Docker/Podman screenshots (an image silently shrinking to its intrinsic size, a popup drifting off its anchor) -- becomes a real, reviewable diff instead, surfaced the same way any other product's visual regression would be. Verified for real: built and ran the actual backend+viewer as two separate origins under Podman (mirroring the separate-host deployment this repo already supports), ran the script against them end to end, and confirmed via the live viewer that the captured "dogfood-run-list" snapshot genuinely shows the viewer's own run list rendered inside itself -- the full recursive loop working, not just individual pieces in isolation. Verification stack torn down completely afterward. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NrQeh9CXrigN1cvpJuyzy4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Answers "how could we take our own product into use in e2e" -- picked the persistent-instance
option (over a throwaway smoke test, or committing baseline PNGs into this repo), since you're
separately standing up a real hosted instance to point this at. Review happens through the real
viewer itself, closing the loop completely.
Fundamentally different lifecycle from
e2e.test.ts's fully ephemeral backend: this scripttargets a real, long-lived instance via
PPS_SERVER_URL/PPS_VIEWER_URL(PPS_API_TOKENoptional -- the same env var convention
packages/clientalready establishes), and neverauto-approves. It captures a handful of the viewer's own key pages -- run list, run detail,
snapshot detail dual/single, Settings, Branches & Releases -- with the real client library,
uploaded under fixed names so repeated runs diff against whatever was previously approved. Each
run also seeds a small amount of fresh demo data (a passing baseline + a genuine regression) so
there's always something real to look at, even on a brand-new instance.
The point: a layout regression in the viewer itself -- the kind this project has so far only
caught by hand via one-off Docker/Podman screenshots -- becomes a real, reviewable diff instead.
PPS_SERVER_URL=https://your-backend PPS_VIEWER_URL=https://your-viewer \ [PPS_API_TOKEN=...] npm run dogfood -w examples/demo-appTest plan
separate-host deployment this repo already supports)
processed, all landed as
approved-baseline-missing(no auto-approve)dogfood-run-listsnapshot genuinely showsthe viewer's own run list rendered inside itself -- the full recursive loop, not just
individual pieces in isolation
npm run lint --workspacescleannpm test --workspaces+npm run test:e2e -w examples/demo-app(14/14) + backendpytest(142/142) -- all unaffected, confirming this addition didn't disturb anythingexamples/demo-app/CODEMAP.mdupdatedCo-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01NrQeh9CXrigN1cvpJuyzy4