Cap every build workflow job at 60 minutes

[slachiewicz]

Only lib-python and lib-python-macos carried a timeout-minutes, so every other job in the build workflow runs to the 6-hour GitHub default when it hangs. lib-d hung in make check on 7 September and held a runner for 47 minutes.

The cap is 60 rather than 30 because the apt mirror, not the work, sets the ceiling. Over the 296 build.yml runs that concluded success or failure between 2026-08-25 and 2026-09-13 (24,228 successful jobs):

Threshold	Successful jobs above it	Runs affected
30 min	16	14 of 296
45 min	1	1
60 min	0	0

All 16 are the same shape: 28 to 42 minutes inside an apt-get install step downloading the libboost-all-dev closure from azure.archive.ubuntu.com, then under 5 minutes for everything else. The longest was cross-test (php, …) at 45.1 minutes in run 34603753680. Per-job budgets do not help here, since the slow step is shared by nearly every job and the compute part is never the problem. 60 fails none of those runs and still frees a stuck runner six times sooner than the default.

The two python jobs keep the 20 they already had. lib-python runs the same apt step, so its 20 has the same exposure, but that value predates this PR.

Verified: parsing build.yml after the change lists all 18 jobs with a timeout-minutes.

This change was created with AI assistance (Claude Opus 5).

[slachiewicz]

30 minutes is still a lot and if You have suggestion what values apply to each module - i can adjust

[Jens-G]

Code review

No blocking issues found. Checked for bugs and CLAUDE.md compliance.

One suggestion, below the bar for an issue but verified:

• 30 minutes also cuts off runs that currently pass. The table in the description covers the last five green master runs. Looking at build.yml runs from 2026-09-02 to 2026-09-11 instead, several jobs succeeded after more than 30 minutes because an apt-get step stalled on the package mirror:

  • cross-test (rb, java,kotlin): 34 min, 33 of them in "Install openssl and certificates" (run 34139215123, push to master)
  • lib-java-kotlin: 37 min, 33 of them in "Install dependencies" (run 33613699571)
  • lib-erl (26.2, 3.27.0): 41 min, nearly all of it in "Install dependencies" (run 34137352657)

  With this change those runs fail and need a re-run. These numbers may help with the per-job values you asked about.

thrift/.github/workflows/build.yml

Lines 1200 to 1202 in 3074a90

	runs-on: ubuntu-24.04
	timeout-minutes: 30
	strategy:

🤖 Generated with Claude Code

[slachiewicz]

Thanks, that was the right check. I extended it to the 296 build.yml runs that concluded success or failure between 2026-08-25 and 2026-09-13: 16 successful jobs in 14 runs exceeded 30 minutes, all of them 28 to 42 minutes in an apt-get install step, none over 45.1. So 30 would have cost a re-run on about one run in twenty. Pushed 92a9675 with 60 instead, which clears every observed case and still cuts a hang from 360 minutes to 60. Per-job values do not buy anything, since the slow step is the same libboost-all-dev download in nearly every job; trimming that closure is a separate change worth measuring; cross-test runs prebuilt cpp binaries, so it likely needs only the boost runtime libraries.

This comment was created with AI assistance.