[juaristi22]

Fixes #2698

What and why

The Test / YAML job's limit goes from 30 minutes to 45.

On 27 October, 8 of the 16 YAML jobs that finished in pull request and merge-queue runs hit the 30-minute limit (two more were cancelled by newer pushes). Each had already logged its N passed summary with no failures. The other 8 took 22 to 28 minutes.

A cancelled YAML job fails Test / Result. In the merge queue, Result runs only once the Python shards finish, about an hour in, and the queue then drops the pull request; adding it back runs the whole suite again. That took #2695 out of the queue today (run 40541059060).

45 minutes leaves room for a slow runner and still stops a hung job. It adds no time to a run, since Result waits about an hour for the Python shards anyway.

This doesn't explain why the job slowed down: on 10 October it took about 4 minutes (run 38085920460). Most of the test step's time now falls outside pytest's own reported duration. In three passing jobs (runs 40496057048, 40516287528, and attempt 2 of 40525399987), pytest reported about 8 minutes, but its 5107 passed summary appeared in the log 16 to 17 minutes into the step, and the step ended about 8 minutes after that.

Test plan

• Policy changes: not applicable, CI only.
• make format: not applicable, no Python files changed.
• Changelog fragment changelog.d/ci-yaml-test-timeout.changed.md (.github/check_changelog_fragments.py passes).
• policyengine_uk/tests/code_health/test_ci_runner_variables.py and test_ci_test_shards.py pass locally (126 passed).
• This pull request's own run passes Test / YAML and Test / Result under the new limit (.github/** counts as code, so the full suite runs).

Reproducer: n/a: CI workflow and changelog fragment only; nothing under policyengine_uk/, pyproject.toml or uv.lock changes.

axiom: n/a: CI only, no policy change

🤖 Generated with Claude Code

[vahid-ahmadi]

Review: #2697 at f464059

The change is right: one timeout-minutes line on the YAML job, and the changelog fragment passes. Because Release test calls the same reusable workflow, the new limit covers both callers. No musts.

Should: 45 minutes is already nearly used up by this pull request's own run

Test / YAML on this pull request (run 40559394037) took 41m36s, which leaves 3.4 minutes of headroom. Here is where the time went in the "Run the YAML tests" step (18:23:06 to 19:03:49):

Point	Time into step
test session starts	0m12s
5101 passed ... in 620.42s (0:10:20)	27m02s
Step ends	40m43s

So the gap after the summary was 13.7 minutes here, longer than the 8 minutes in the description, and the description's "passing jobs take 22 to 28 minutes" is already out of date. The Release test / YAML job for the same commit took 23m17s, so the spread between runners is wide. On the next slow runner, 45 will cancel a job that has passed, which is the failure this pull request is meant to stop.

Your own argument supports a higher limit: Result waits about an hour for the Python shards, so a limit of 60 adds no wall-clock time to a normal run and still stops a job that hangs. I suggest 60, and updating the comment and changelog wording to give the range we have now seen (23 to 42 minutes). If you'd rather keep 45, please note in the description that this run used 41.6 of it.

Note

• You can tick the last test-plan box: this run passed Test / YAML and Test / Result under the new limit.
• The real fault is the time after pytest's summary, which grew from about 8 to 13.7 minutes. A higher limit only buys time; The YAML test job hits its 30-minute limit after its tests pass #2698 should stay open for the root cause.

I'll approve once the limit question is settled either way.

🤖 Generated with Claude Code