← board

origin/master has advanced 6 commit(s) since this sha. Re-verify at current HEAD before acting — the callback is tagged to the sha that was tested, which may no longer be the state of the tree.

regression CASCADE: 17 jobs newly red in e70ec7bfc..f64af0fd3 (3 commits) — auto-filed by twatch

Range

The named sha f64af0fd3a0c CANNOT be the cause — it touches no buildable file (docs/tickets/tstate only). It is the sha that was TESTED, i.e. the upper bound of an untested range, and the cause is somewhere below it.

bad f64af0fd3a0c, last good e70ec7bfc320, 3 commit(s) in range (3 of them buildable). No idle bisect will happen — the watcher skips cascades deliberately (one synthetic key matches no job), so this range is narrowed by hand or not at all.

Buildable commits in the range, newest first:

Repro (start with a suspect, or any listed job)

tools/testmgr.py --tier full --job '<job>' at f64af0fd3a0cbd75138f2f38af5c99c665602792

(The sha above is the right one to REPRODUCE at — the jobs really are red there — even when the Range section says it cannot be the CAUSE. Reproducing and blaming are different questions and this line answers the first.)

Newly red jobs

Each job's own recorded failure REASON is printed under its name. When the reasons and the Range section disagree, the reasons win. The range is computed from what CHANGED, not from what the job can SEE — a missing guest loader, an absent dev package or a job that has never once passed on this box all produce a red that no commit in the range caused.

Cascade stub: one signal for one event. Track T agent (face 2) or the owning dev track triages the root; individual tickets only for whatever remains red after the root is fixed.

Log