Plan one working happy path for every command the binary answers to - #170
Plan one working happy path for every command the binary answers to#170wmadden-electric wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 94 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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. Comment |
commit: |
wmadden-electric
changed the title
44b8df9 to
4fd7080
Compare
The binary answers to 89 commands, counted by walking --help from the root. 40 have an e2e test. 49 do not. The requirement is one happy path per command, run through the assembled binary and succeeding — not --help, not "it parses its arguments". The product repos test their own commands exhaustively but cannot reproduce the configuration this binary assembles: the mount paths, the linked engine version, several families' config sections at once, the credential wiring, and the published tarball's dependency tree exist only here. The 49 are blocked on a handful of shared fixtures rather than on themselves, so the plan orders the fixtures: a deployed service unlocks about 16, an ORM project directory unlocks most of that family, a database unlocks the rest. Four commands need a ruling before anyone writes them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
4fd7080 to
d4f0318
Compare
wmadden-electric
changed the title
|
Closing as superseded, and stale enough to be worth saying why. The convention this planned already exists in enforced code — This document went stale in a day, which is the argument against keeping it:
The one paragraph worth keeping is the rationale — why this repo owes a happy path per command, rather than leaning on the product repos, with #171 as the proof. That moves into the header of |
The rule was stated; the reason was not, and it lived in a plan document instead. Plan documents go stale silently — that one said 40 of 89 commands were covered and that only Composer could produce a deployment, both wrong within a day. This file fails CI when it rots, so the reason belongs here beside the rule it justifies. Rescued from the closed PR #170. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
The rule was stated; the reason was not, and it lived in a plan document instead. Plan documents go stale silently — that one said 40 of 89 commands were covered and that only Composer could produce a deployment, both wrong within a day. This file fails CI when it rots, so the reason belongs here beside the rule it justifies. Rescued from the closed PR #170. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
2 participants
The
prismabinary answers to 89 commands. 40 have an e2e test. 49 do not.Counted by walking
--helpfrom the root through every group, diffed against thedescribeCommandblocks inpackages/cli/e2e/*.e2e.ts. Nothing in the suite names a command the binary does not mount.What the test has to be
One happy path per command, run through the assembled binary, doing the thing and succeeding. Not
--help, not "it parses its arguments", not "it fails honestly without credentials" — those prove a command is reachable, not that it works.The reason this repo has to do it rather than lean on the owning repos: the product repos test their commands exhaustively, but none of them can reproduce the configuration this binary assembles. The mount paths, the engine version actually linked, several families' config sections at once, the credential wiring, and the dependency tree inside the published tarball exist only here. A command can pass its owner's entire suite and still be broken the moment it is mounted.
26 of the 49 come from other packages — 22 from
@prisma/orm-toolchain, 4 from@prisma/composer— and not one is run by this repo's e2e suite.The fixtures decide the order, not the command groups
Most of the 49 are blocked on the same few things, so the work is to build those and the commands follow in bulk:
service deploymentverbs,service open,service show, the fiveservice domainverbs, andbuild logs. Highest value and most expensive: it creates real infrastructure the suite must then remove.format,orm init,contract, the eightmigrationverbs,ref. No API needed;tests/fixtures/orm-projectalready exists to build on.db init|schema|sign|update|verifyandmigrate. The suite already creates Prisma Postgres databases, so this is wiring.git connect|disconnect, a second workspace forproject transfer, a project with real backups forpostgres restore.Four need a ruling before anyone writes them
auth logindrives a browser, and every other test authenticates with a service token — so the one command whose job is obtaining a credential is the one the suite cannot exercise normally.feedbackposts real feedback to the CLI team unless it can be pointed at a test endpoint.composer dev/lognever settle on their own, so "happy path" needs a definition — started, served one request, shut down cleanly.lspspeaks LSP on stdio; its happy path is an answeredinitialize, a different harness from everything else here.Plan only, no code. Nothing to be written as a skipped test in the meantime — a skipped test reads as coverage.