ci: give every job a timeout so a hung runner fails fast #304

2026-10-16T10:57:50Z

rvnminers-A-and-N commented

2026-10-16 10:57:50 +00:00

No CI or desktop-packaging job set timeout-minutes, so a runner that stops responding holds a PR for GitHub's six-hour default. #301's macOS Intel build sat on a plain go build for over twenty minutes and ignored a normal cancel.

Each job now gets roughly three times its longest recent successful run on dev:

Job	Longest recent	Timeout
scope (both workflows)	<1m	5m
test	19m	45m
workload-architecture	4m	15m
workload-elsewhere	7m	20m
rehearsal	3m	15m
desktop	11m	30m
package	21m	60m

release.yml is left alone, since it only runs on a tag and a slow release build is better finished than cut off.

actionlint passes.

No CI or desktop-packaging job set `timeout-minutes`, so a runner that stops responding holds a PR for GitHub's six-hour default. #301's macOS Intel build sat on a plain `go build` for over twenty minutes and ignored a normal cancel. Each job now gets roughly three times its longest recent successful run on dev: | Job | Longest recent | Timeout | | --- | --- | --- | | scope (both workflows) | <1m | 5m | | test | 19m | 45m | | workload-architecture | 4m | 15m | | workload-elsewhere | 7m | 20m | | rehearsal | 3m | 15m | | desktop | 11m | 30m | | package | 21m | 60m | `release.yml` is left alone, since it only runs on a tag and a slow release build is better finished than cut off. actionlint passes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Sisyphus/Sisyphus#304