Repository navigation
fix(verify): put the browser acceptance records back when the run is over - #230
Merged
Merged
Conversation
…over A verification run rewrites the tracked acceptance records — every record carries the time and the machine it ran on — so the working tree is dirty once the suites are over. The release packaging runs in a separate process afterwards and refuses to run with a dirty tree, so the CLI release build failed with "Packaging requires a clean committed working tree". The suites that write a record restore what they wrote, but one of them did not: the isolated-chromium suite in browser-use-real-input.test.ts. It only runs where the system Chrome sits on a Linux path, so the gap only ever showed up on the Linux CI job. Two things now hold the tree: - the suite restores its own record, the way the other four do; - the verification run restores every tracked record from HEAD when it is over, so a suite that forgets cannot break the packaging gate again. The restore is git-based on purpose: it restores the committed content of every record file, and it does not depend on which process wrote it. Locally the records stay — they are what the run just produced, and the published matrix is written from them.
modacker
force-pushed
the
fix/verify-restore-acceptance-records
branch
from
October 22, 2026 22:37
d2efcc8 to
14845e2
Compare
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.
What broke
The CLI release build failed with:
The packaging step runs in its own process after
pnpm verifyand refuses to run against a dirty tree. The tree was dirty because the browser acceptance records are tracked files that every run rewrites — each record carries the time and the machine it ran on.Why the earlier fix did not cover it
#228 gave the suites that write a record a way to put back what they wrote:
restoreAcceptanceRecords()inpackages/webui/test/browser/acceptance-record.ts, called from four suites.One suite was missing: the isolated-chromium suite in
browser-use-real-input.test.ts. That suite only runs where the system Chrome sits on a Linux path (/usr/bin/google-chromeand friends), so it never ran on a macOS or Windows machine — the gap only ever showed up on the Linux CI job.What this changes
browser-use-real-input.test.tsrestores its own record, the way the other four do.scripts/lib/acceptance-records.mjs), so a suite that forgets cannot break the packaging gate again.The run-level restore is git-based on purpose: it restores the committed content of every record file and does not depend on which process wrote it. Locally the records stay — they are what the run just produced, and the published matrix is written from them.
How it was checked
.plan/browser-use/complete/isolated-chromium.acceptance.jsonmodified, and the packaging script then reportsPackaging requires a clean committed working tree.node --test test/source-sync.test.mjs: 59 tests, 0 failures — including a new test that pins the property against a throwaway checkout.pnpm verify --profile docs: 4 gates pass, and the records are restored at the end of the run.Not addressed here
The isolated-chromium suite's own Chrome probe is still Linux-only, so it does not run on macOS or Windows. That is why the gap was invisible locally. Widening the probe changes what a local
pnpm verifydoes on those platforms, so it is left for a separate change.