ci(website): print the deployed docs URL and smoke-check it#99
Merged
Conversation
The deploy workflow could report success while telling you nothing about where it published, and a green deploy is not a serving site — PRO-200 is exactly that failure: a compute service returns a successful deploy and a permanently 404ing domain. The URL is also a generated service id, so without printing it a run gives no way to find what it just shipped. Adds scripts/verify-deployed.ts, run as the last step of the deploy: it resolves the service through the Management API with the credentials CI already has, prints the URL (also to the run summary), then polls the landing page and a guide route until both serve the docs, failing if they never do. - The app and service names come from module.ts / src/service.ts rather than string literals, so renaming either cannot silently break this. - More than one matching service is a hard failure, not a guess: the API reports branchId: null for every compute service, production and stage alike, so a second one makes "which is production?" unanswerable. It prints the candidates and says how to clear them. - @prisma/management-api-sdk is a devDependency, matching pn-widgets: it is CI-only and never reaches the deployed bundle. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
commit: |
Both comments described the code as something it is not. The probe comment said the marker string comes from every page header. It does not: the header renders `Prisma <span>Composer</span>`, so the raw HTML never contains those two words together. The string it actually matches is in the <title>, the meta description and the footer. The check is sound and the conclusion holds — all three come from template.ts s shell, not from a guide s markdown, so editing the docs cannot break it — but the stated reason was wrong. The header comment claimed reading the names off module.ts / src/service.ts means renaming cannot "silently" break the check. Hardcoded names would fail loudly, not silently. The actual benefit is narrower: one definition per name instead of a second copy to keep in sync. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
wmadden
approved these changes
Jul 16, 2026
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
2 participants
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.
The
deploy-docsworkflow could report success while telling you nothing about where it published — and a green deploy is not a serving site. PRO-200 is exactly that failure mode: a compute service returns a successful deploy and a permanently 404ing domain. The URL is a generated service id, so without printing it a run gives no way to find what it just shipped.Adds
website/scripts/verify-deployed.ts, run as the final step of the deploy. It resolves the service through the Management API using the credentials CI already has, prints the URL (and to the run summary), then polls the landing page and a guide route until both serve the docs — failing if they never do.Notes for the reviewer
module.ts/src/service.tsrather than repeated as strings here, so each name has one definition instead of a second copy to keep in sync.branchId: nullfor every compute service — production and stage alike — so a second one makes "which is production?" unanswerable. It prints the candidates and says how to clear them, rather than verifying the wrong environment and reporting green.@prisma/management-api-sdkis a devDependency, matchingexamples/pn-widgets. It's CI-only and never reaches the deployed bundle (the site's runtime imports are unchanged).scripts/is excluded from the dependency-cruiser sweep, so this doesn't touch the public-imports-only rule.Verification
siteservices, it fails with both ids listed and a non-zero exit, instead of picking one.m2u4w6w93v8m1hkc8bdl4wzz.ewr.prisma.build): landing and/guides/getting-startedboth return 200 and contain the string the check looks for. That string (Prisma Composer) appears in each page's<title>, meta description and footer — all emitted bytemplate.ts's shell, never by a guide's markdown — so editing the docs can't make this flaky.--frozen-lockfile, biome, typecheck, andlint:depsgreen.The happy path can't be run from a laptop — the CI workspace token isn't available locally — so the first real end-to-end proof is this workflow's own run on merge.
🤖 Generated with Claude Code