Repository navigation
fix(docs): start the fixture server before tutorial CLI steps that need it - #4444
Conversation
Failing tests for a throwaway CLI home built from the real one: a copy of modules/, a link to the Lucee express runtime, no cache, and the CLI pointed at it through LUCLI_JAVA_ARGS (-Dlucli.home) and LUCLI_HOME. Refs #4422 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
Every {test:cli} block ran the installed wheels CLI in the developer's own
home, so `wheels packages registry refresh` deleted ~/.wheels/cache/packages
and fixture apps went through the same server registry.
verify:docs and test:docs-harness now build a temporary home: modules/
copied (so CI's checkout overlay is used), express/ linked, nothing else.
The CLI is pointed at it with LUCLI_JAVA_ARGS=-Dlucli.home (the Homebrew
launcher resets LUCLI_HOME) and LUCLI_HOME, and it is removed on exit. One
serial `wheels system paths` sets up the fresh home before blocks run in
parallel, which otherwise race on it. The run prints the home it used.
Closes #4422
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Peter Amiri <peter@alurium.com>
…out of the real home - SIGINT / SIGTERM now exit normally, so the exit handler removes the throwaway home instead of leaving it in the temp directory. - express/ is a copy-on-write copy of the real runtimes, not a link, so a Lucee download or a JDBC driver staged into lib/ext stays in the throwaway home. Closes #4427. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
…ed it The mini-tutorial's step 1 runs wheels reload, but the tutorial session only started the fixture's server for HTTP asserts, so the reload refused and the harness test failed on every run. CLI steps whose command talks to the dev server (reload, routes, test, migrate, seed, console) now start it first. The harness workflow step is blocking again. Closes #4426. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
|
rev1-r3 review @ c1378be: code APPROVE (final pending PR CI) This replaces #4430, which closed automatically when #4428's merge deleted its base branch. I compared the changed lines of The final waits on PR CI, and specifically on the |
|
rev1-r3 review @ c1378be: APPROVE (final) PR CI is now 19 pass / 0 fail / 0 pending, with 4 skipping. The now-blocking Ready to merge. One thing to watch: #4447 (bounding harness commands) is the fix for the intermittent test-51 timeout seen on #4441. Once this lands, a recurrence of that timeout will block merges until #4447 is in. |
Closes #4426.
Summary
The docs-harness unit test "tutorial driver walks mini-tutorial end to end" failed on every run (
not ok 59), locally and in docs-verify. The workflow step'scontinue-on-errorhid it.Step 1 of the fixture runs
wheels reloadas a{test:cli}block, butTutorialSessionstarted the fixture's server (ensureServer()) only for HTTP assertions. So no server was running, andwheels reloadrefused: "Reload requires this project's own server".applyCliExample()now starts the fixture's server first when the step's command talks to the dev server, as a reader following the tutorial would have runwheels start. Those commands arewheels reload,routes,test,migrate,seedandconsole(needsServer()). Other commands, includingwheels start/stop/generate/new, run as before.With the harness green, the docs-verify "Run harness unit tests" step is no longer
continue-on-error.Tests
node --import ./scripts/verify-docs/test/isolated-home-setup.mjs --test --test-name-pattern=mini-tutorial scripts/verify-docs/test/tutorial.test.mjsfails withstep-1.mdx:26 failed: expected exit 0, got 1 / Reload requires this project's own server.tutorial.test.mjsgives 9 pass, 0 fail, including a new unit test ofneedsServer(). The fullpnpm test:docs-harnessgives 69 pass, 0 fail.servers/andexpress/listings were the same before and after the full run.🤖 Generated with Claude Code