Story: Cap the Nightly Build step below the six-hour job limit
Table of Contents
This page documents a story in Sprint 28. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
A Nightly Build whose compile overruns stops with enough of the job left to persist its compiler cache.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 28 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-15 |
3. Acceptance
- The Run CTest workflow step in nightly-linux.yml has timeout-minutes 320.
- The remaining job budget covers the cache guard, delete and save.
- A warm Nightly Build run is unaffected.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Scaffold story: Cap the Nightly Build step below the six-hour job limit | DONE | 2026-10-15 | 2026-10-15 | Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR. |
| Add the 320-minute cap to the Nightly Build step | DONE | 2026-10-15 | 2026-10-15 | Initial task for: Cap the Nightly Build step below the six-hour job limit |
5. Decisions
- The cap is 320 minutes, the same value
continuous-linux.ymluses, so the two workflows explain the same arithmetic in one place rather than two. - The cap is on the step, not the job. The job limit is already 360 minutes and cannot be raised on a hosted runner, so the only way to keep room for the cache steps is to stop the build early.
- The gcc job's runner shutdown is left alone. It is infrastructure, it happened at 3h13m, and no timeout change affects it.
6. Out of scope
- Diagnosing why the runner shut down. That is GitHub's, and the same signature has hit Linux jobs repeatedly this month.