A 45 minute job cap has to cover two full coverage runs, so openregister PRs cannot pass

[rubenvdlinde]

Three openregister branches hit this on 2026-09-10 and it is structural rather than bad luck.

The mechanism

quality.yml's PHPUnit job runs the suite twice: once at the head, then again in Measure merge-base coverage at the merge base. Both runs are under xdebug coverage. The job carries timeout-minutes: 45.

So once a single run exceeds roughly 22 minutes, the job mathematically cannot pass, and a re-run fails identically.

Measured

	duration
run 34350030815, 2026-09-09	3m14s
the same step, 2026-09-10	40m47s

Roughly thirteen times slower, same step, same config. Only two npm-dependency commits landed on development in between, and neither can touch PHPUnit.

The head run itself passes: 19,506 tests, 47,952 assertions, zero errors, zero failures, 62.05% coverage. What fails is the second run, of unmodified baseline code, killed at the cap with The job has exceeded the maximum execution time of 45m0s.

Why it matters beyond one PR

Three independent branches hit it the same morning, including the one repairing spec anchors that was blocking every other openregister pull request. A cell that is red for everyone carries no information, and this one is red for a reason unrelated to any change it is judging.

Shapes of fix, not a recommendation

• Raise the cap for repositories whose suite genuinely takes this long.
• Measure the merge base once per base commit and cache it, rather than per PR.
• Skip the merge-base run when the diff touches no PHP.
• Establish why the suite went from 3 minutes to 41 in a day, which may make the rest moot.

The last one is worth doing first, because a thirteenfold slowdown with no relevant commits in between is itself a finding.