fix(website): keep the post-promotion e2e run off the local fixture runtime - #983
Merged
Conversation
…untime The deploy job re-runs the ordinary Website suite against production with only BASE_URL set, and #982 let that step run for the first time since the custom-target specs landed. Two failure clusters surfaced, both invisible to PR CI by construction because only the push-only deploy job runs the suite against a remote origin: - Twelve custom-runtime-target cases dial a fixture runtime on 127.0.0.1:4399 and the local example apps. Those exist only because the Playwright config starts them, and it starts nothing when BASE_URL is set, so every case failed with ECONNREFUSED after the site had already promoted. The config now ignores the fixture-driven specs whenever it starts no local server, including production-smoke mode. - The reduced-motion check held the runtime in its configuring state by refusing http://localhost:4300. Against the deployed site the frame loads from the production runtime origin, the handshake completes within half a second, and the loader is gone before the assertion. The route now matches the runtime frame by the session params Run mode stamps on every runtime URL, which holds the loader on screen locally and in production alike. Verified by running the full suite against https://threadplane.ai exactly as the deploy step does: 105 passed, 0 failed (was 104 passed, 13 failed). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
blove
added a commit
that referenced
this pull request
Sep 3, 2026
…tomation bypass (#984) With #983 the deploy job reached "Exhaustively verify immutable cockpit preview" for the first time, and it failed on its first probe: [preview] root default redirect: expected 308, received 302. The 302 is Vercel deployment protection sending every path on the unaliased artifact to vercel.com/sso-api — the same wall #974 removed for the Website preview. Bypass secrets are issued per Vercel project, so the Website secret cannot open the cockpit deployment. - deploy-smoke.ts sends `x-vercel-protection-bypass` on every probe when VERCEL_AUTOMATION_BYPASS_SECRET is set, read from the environment so the value never lands in argv or step logs. A 302 to the SSO endpoint now names deployment protection and the missing secret instead of reporting a bare status mismatch. - The workflow step supplies the secret from VERCEL_COCKPIT_AUTOMATION_BYPASS_SECRET and fails with a provisioning message when it is unset. - Unit tests cover the header on every probe (including the hostile-header case), its absence without a secret, and the SSO hint; the workflow guard asserts both preview checks carry their own project's secret. Requires the repository secret VERCEL_COCKPIT_AUTOMATION_BYPASS_SECRET. Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Sep 4, 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
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.
Why
#982 fixed
vercel promote, and the Website promoted to production for the first time since 2026-09-01 on run 33762212520. The very next step, Verify deployed website, then failed with 13 red tests, sorefs/deploy/last-promotedstill has not advanced and the cockpit redirect service never deployed.Both clusters are failure paths PR CI cannot see: only the push-only deploy job runs the ordinary Website suite against a remote origin.
What failed
12 ×
custom-runtime-targets.spec.ts—connect ECONNREFUSED 127.0.0.1:4399. The spec drives a fixture runtime and the local example apps that the Playwright config starts aswebServerentries. WithBASE_URLset the config starts nothing, so there was never anything to talk to.1 ×
workspace-shell.spec.tsreduced-motion — the test held the runtime in its configuring state by abortinghttp://localhost:4300/**. Against production the frame loads fromexamples.threadplane.ai, reachesreadyin ~500 ms, and the loader the assertion looks for is already gone.Fix
playwright.config.ts: whenever no local server starts (remoteBASE_URL, production smoke), ignore the fixture-driven specs. Local, production-build, and BFCache modes are unchanged.workspace-shell.spec.ts: abort the runtime frame by thecockpit_capsession param Run mode stamps on every runtime URL, not by host. Probed against production: the loader stays on screen for the full 5 s configuration window under this route.playwright-config.spec.ts: unit tests for the remote-target ignore list and a source guard against reintroducing the host-bound route.Evidence
Full suite run locally exactly as the deploy step does (
BASE_URL=https://threadplane.ai npx nx e2e website):Config unit tests: 9/9. Lint: only pre-existing warnings.
🤖 Generated with Claude Code