Restore existing result loading in allure watch - #976
spetrianni wants to merge 5 commits into
Conversation
Make --new-only opt-in again, document startup behavior, and cover initial and live ingestion across discovery modes. Co-authored-by: Copilot <[email protected]>
|
|
|
Thanks for the detailed writeup and the regression tests. The diagnosis is exactly right: The default flip is the piece I'd like to reconsider, though.
That said, the current behaviour fails badly: the report is silently empty, and there is no way for the user to tell that a backlog was skipped rather than that something is broken. Documenting So I'd suggest keeping the default and making the skip visible instead. The phase is already known in let skippingBacklog = this.newOnly && isInitialDiscovery;
const watcher = newFilesInDirectoryWatcher(newDir, async (path) => {
if (skippingBacklog) {
skippedResults++;
return;
}
await allureReport.readResult(new PathResultFile(path));
});
await watcher.initialScan();
skippingBacklog = false;and after the discovery watcher's initial scan: if (skippedResults > 0) {
console.info(`skipped ${skippedResults} existing result(s); pass --no-new-only to load them`);
}The progress plugin only clears its own line and explicitly protects foreign writes, so this stays in the scrollback and remains visible for the whole session. Concretely, what I'd like to keep from this PR:
And drop the one-line default change in favour of the counter plus the startup notice. If you'd rather not extend the scope, I'm happy to take the counter part in a follow-up and land the docs and tests from here first. |
Co-authored-by: spetrianni <[email protected]>
Co-authored-by: spetrianni <[email protected]>
Co-authored-by: spetrianni <[email protected]>
Restore default `--new-only` semantics for `allure watch`
There was a problem hiding this comment.
@todti Agreed with your suggestions, please proceed with the review. I left the default behavior set to new-only
Context
allure watchcan start with an empty report even when valid results already exist in the selected directories.The regression was introduced in #816 (
76343c89):--new-onlywas added with a default oftrue. Consequently, the initial file scan usedignoreInitial: true, indexed the existing files without callingAllureReport.readResult, and never picked those files up on subsequent scans. This affected name-based discovery, explicit directories, CLI globs, andconfig.resultsDirpatterns.Changes
--new-onlyopt-in (falseby default).--new-onlyand--no-new-onlybehavior, live ingestion, and the existing rule that directories discovered after startup always load their backlog.allure watchallure watch --new-onlyallure watch --no-new-onlyNo changes to the reader, report rendering, shared watcher implementation, or
run/agentdefaults are needed.Regression evidence
Following
AGENTS.mdanddocs/allure-test-agent.md, test executions used Allure agent mode with fresh managed output directories and explicit scope expectations.Before the fix, the new watch coverage produced 5 failures and 18 passes: all four default-mode discovery variants incorrectly received
ignoreInitial: true, and the real file-watcher scenario did not ingest the existing result. Explicit flag scenarios passed. The failed run also recorded the expected nonzero test-process global error; its stderr and per-test evidence were reviewed, rather than treating the partial modeling status as a success.After the fix, the focused run produced 24 passed, 0 failed, 0 skipped, exit 0. Expected scope matched; the final runtime model was complete and the findings manifest was empty. Reviewed
index.md,manifest/run.json,manifest/test-events.jsonl,manifest/tests.jsonl,manifest/findings.jsonl, and the relevant per-test steps.The real watcher now forwards one existing result and one live result by default; with
--new-only, it forwards only the live result.--no-new-onlyforwards both. All three scenarios assert no duplicate ingestion during shutdown.Locally, Yarn was invoked through the repository-pinned
node .\.yarn\releases\yarn-4.15.0.cjslauncher because a global Yarn executable was unavailable. The initial root workspace build completed successfully, and the changed CLI package was rebuilt after the fix. Targeted standard Oxlint and Oxfmt checks, plus the normal pre-commit hooks, completed successfully.Validation limits
This is focused CLI/file-watcher coverage, not a full-suite, cross-platform, or browser-rendering claim. The ingestion tests use the real file watcher but mock report generation and the HTTP server. Local execution was on Windows with Node.js 26.8.2 and Allure 3.17.0.
The additional native
oxlint --type-awareattempt could not complete: it reported unresolved Node type definitions and arootDir/common-source-directory configuration diagnostic in this local Yarn PnP checkout. It is not counted as passing validation; the CLI's existing TypeScript build did pass. No unrelated configuration changes were made to work around it.Checklist