Pair the torch-nightly triage by day against the pinned nightly

[atalman]

Why

The triage compared a torch-nightly build only against a baseline that ran the same commit within 900s. That held while both fired in the same cron slot. It stopped holding when torch-nightly moved to 10:00 and the baselines stayed at 06:00/21:00 — four hours of merges apart, they can never agree on a commit again.

find_latest_pair walks newest-first and skips any nightly without a match, so rather than reporting nothing it silently pinned every run to the last same-commit pair, #82789/#82790 from 2026-08-07. The workflow kept succeeding and #8491 kept being told "still reproducing on #82789" while #83159, #83338 and #83539 went unexamined. No failure, no warning — just an increasingly old build number.

83539  Aug 12 10:00  ->  no same-commit baseline   skipped
83338  Aug 11 10:00  ->  no same-commit baseline   skipped
83159  Aug 10 15:14  ->  no same-commit baseline   skipped
82789  Aug  7 06:00  ->  82790                     selected

What changes

1. Pair on the same UTC day rather than the same commit.

	same-commit	same-day
torch-nightly builds paired (21d)	6/12	12/12
baseline chosen on the 6 days both rules work	—	identical

Nothing regresses; the coverage gap closes.

2. Prefer Full CI run - nightly over Full CI run - daily, then closest in time. The plain nightly is the pinned-torch counterpart of the torch-nightly build — same pipeline, same schedule, differing only by TORCH_NIGHTLY=1. Under a time-first ordering, 2026-08-10 would have compared against the daily (+5.8h) instead of the pinned nightly (-9.2h).

Resulting pairings over 21 days — every one against a pinned - nightly:

83539  2026-08-12 -> 83511 (nightly  -4.0h)
83338  2026-08-11 -> 83298 (nightly  -4.0h)
83159  2026-08-10 -> 83094 (nightly  -9.2h)
82789  2026-08-07 -> 82790 (nightly  +0.0h)
82682  2026-08-06 -> 82629 (nightly  -7.4h)
82454  2026-08-05 -> 82455 (nightly  +0.0h)
...

The trade-off, made explicit

With different commits the pair is no longer a controlled A/B — a regression may come from vLLM commits landing between the two builds rather than from torch. Reports now say which case they are:

⚠️ The two builds ran different commits (6accb779a361 vs 02ac17851dfb), so this is a same-day comparison rather than a controlled A/B. A regression here may be caused by vLLM commits landing between the builds rather than by torch nightly.

plus the ±Nh gap and both commits in the summary table (which gains a commit column). Same-commit pairs read exactly as before.

Test plan

• find_latest_pair against live ClickHouse rows now returns #83539 (torch nightly, Aug 12 10:00) vs #83511 (pinned nightly, Aug 12 06:00); before: #82789/#82790 from Aug 7.
• Simulated over 21 days: 12/12 paired (was 6/12), all against - nightly, identical to the old choice on every day the old rule worked.
• Job-set sizes are comparable across the three build types (315–321 distinct job names), so the comparison is not skewed by one type running a materially different set.
• Rendered a report both ways — the warning appears only when commits differ.
• ruff check / ruff format --check clean.

Fixes the staleness behind #8491.

Authored with the assistance of Claude Code.

[vercel]

@atalman is attempting to deploy a commit to the Meta Open Source Team on Vercel.

A member of the Team first needs to authorize it.

[morrison-turnansky]

As long as we are good with potentially picking up manual runs instead of cron jobs we should be good. Since it will still favor same commits, I don't see that as a problem.

[atalman]

HI @morrison-turnansky yes picking up manual runs is expected. This is how we where running so far.