CI: bisect a red main build to the pull request that broke it

[LeandroLP23]

Proposal: when a main build turns red, a workflow bisects the merges since the last green build on the failing job and names the pull request that broke it. It costs nothing while main is green and doesn't change how pull requests are built.

Why

Since 0ab2a04, full builds run on pull requests only when started by hand, and on main after merges. During merge waves most main builds never run. Between 2026-10-11 19:00 UTC and 2026-10-12 06:40 UTC, 241 pull requests were merged. Of the 200 main build runs in that window, 176 were cancelled as superseded, 12 passed and 10 failed. A red run therefore covers dozens of merges, and finding the cause took a manual bisection each time. Three Windows regressions went in that night:

Merged	What broke	Found by	Fixed by	Broken for
#3462 (21:24)	Windows build (HostPoll undeclared in Socket.cpp)	#4021	#4021 (23:30)	~2 h
#3594 (21:39)	agc_write_tracking on Windows	manual bisection in #4087	#4131 (00:29)	~3 h
#3788 (22:01)	guest_kernel_stack_protect on Windows	#4088	#4169 (01:41)	~3.5 h

None of the three was careless. Each pull request was tested by its author: on Linux, where the Windows path doesn't run, or with a focused test that didn't include the one that broke. While the Windows build was broken, every Windows run (fork CI, local checks of other pull requests) failed for a reason unrelated to the change being checked. Several people bisected the same failures in parallel.

What it would do

1. On a failed main run, take the first-parent merges between the last successful run and the failing commit.
2. For each failing job, bisect those merges on that job's runner. Each step builds the merge and runs only the tests that failed. A build failure is itself the failing step.
3. Comment on the first bad merge's pull request with the failing test and its output, and open an issue that links it, or update the existing one.

A bisection over 64 merges takes about 6 steps. With ccache, each step is an incremental build plus a few tests. This runs only when main is red, not per pull request.

Smaller option

If even that is too much, a label alone would help. A pull request whose diff touches #ifdef _WIN32 code or Windows-only files, and whose description declares no Windows run, gets a windows-untested label. People with Windows machines can then check those before merging.

I can implement either one as a pull request, if the approach is acceptable. Feedback on the cost and runner limits is welcome before I start.

[LeandroLP23]

One limit of this proposal, found with #4435: it only catches what CI can see. Since #4152, 47 AGC tests have crashed on AMD's Windows driver (Radeon 860M). Upstream CI runs the GPU tests on lavapipe, though, so main stayed green and nothing would have started a bisect. The windows-untested label wouldn't have caught it either: #4152 had been tested on Windows, on NVIDIA. I found it running the AGC suite on that hardware, bisected it by hand, and the fix is in a PR for #4435.

So for GPU code the gap is hardware coverage rather than Windows coverage. Two cheap ways to narrow it, without new runners:

• A needs-hardware-run label (or a template line) for PRs that change pipeline creation, the shader recompiler or the AGC driver. It asks for a ctest -R '^agc_' -j 1 run on at least one GPU vendor other than the author's before merge.
• A pinned "hardware testers" discussion, where contributors list the GPU, driver and OS they can run the suite on. A reviewer can then ping the right person instead of waiting for a report after the merge.

Periodic runs on real GPUs would cover more, but they need self-hosted runners. I'm happy to be the AMD RDNA 3.5 / Windows entry on such a list.