eccdddfb22cf35d4e5698f72a4b12707aa43b349 braney Sun Sep 20 14:27:27 2026 -0700 testRegistry: check the docent column's "-" as well as its names The docent column says which browser test watches the same ticket, and a named script was already checked: it has to exist and has to belong to that ticket. A "-" was checked by nothing, and that was the wrong half to leave out. `unwatched` -- the list of tickets where nothing anywhere would go red if the bug came back -- is built entirely out of those "-" values. They were entered by hand, by reading the docent directory once, so a script written the next day left the ticket sitting on that queue with nothing to notice. For the four tickets that are on it because their code lives inside a CGI, somebody writing the docent script is the expected outcome, which made it the likeliest kind of row to go stale. So a row claiming no docent script is now checked against the tree the same way a named one is: if rm<ticket>.*docent.yaml turns up, the check fails and asks for the row to be filled in. The failure is somebody doing the right thing and the table not having heard about it. Watched to fail and then pass: blanking the docent column of #36212, whose script is in the tree, turns the real table red with the name of the script it found. refs #38391 diff --git src/utils/testRegistry/README src/utils/testRegistry/README index cfca2e6d97d..e9c6b6013b4 100644 --- src/utils/testRegistry/README +++ src/utils/testRegistry/README @@ -36,32 +36,38 @@ Measure work done -- queries, passes over the data, allocations, bytes of cache -- and never wall-clock seconds, because a test that times a loop goes red on a busy machine and then gets deleted. library the fix is in library code that a browser reaches only through a page, where a dozen other things can go wrong first and produce the same red. A ticket whose fix only changes what a page says is not in the table at all. That is the docent suite's job, refs #38252. The docent column names that suite's script for the same ticket, or "-". Many tickets have both, and should: a docent script watches the page and a unit test watches the thing the page cannot show. What the column is really for is `unwatched`, the tickets with neither, where nothing anywhere would go red if the -bug came back. `check` verifies the script exists and belongs to that ticket, so -this column rots no more quietly than the other one. +bug came back. + +`check` verifies both values, which matters more than it sounds. A named script +has to exist and has to belong to that ticket. A "-" has to still be true: if +somebody writes rm<ticket>.docent.yaml later, the check fails and asks for the +row to be updated. Without that second half the "-" rows would be the one thing +in this file nothing verified, and `unwatched` is built entirely out of them, so +a ticket could sit on that queue long after it had left it. The rule is about the change, not about where the file lives. A wording fix that happens to touch hg/lib needs no unit test; a performance rewrite inside hgTracks needs one badly. Sorting by directory gets both of these backwards. Scope ----- Unit tests, and tickets from v504 on. The browser-page regression tests are a different thing and already have their own registry: the docent suite, refs #38252, names each script for its ticket and tallies its own evidence with `make proof`. Putting both in one table would have buried a dozen unit tests under ninety-five browser ones. Starting at v504 rather than at the beginning is deliberate. A registry that