Summary
The static-analysis job's cppcheck step timed out twice in a row on the
same PR (#591, no code changes between attempts) against its declared
timeout-minutes: 15:
- Attempt 1 (run 32863372600, job 97852566480): cppcheck logged
"clean — zero findings" at 117/117 files, then the job was cancelled
a fraction of a second later (##[error]The operation was canceled.),
total duration 15m10s.
- Attempt 2 (rerun, job 97858198802): the
Run cppcheck step alone ran
15:19:43Z → 15:34:42Z (14m59s) and was killed with the cppcheck process
still active (Terminate orphan process: pid (2729) (cppcheck)).
Both runs used the identical checked-out diff. This is not a one-off flake
in either the code or a single bad runner -- it's the job's 15-minute
budget being right at (or under) the actual time cppcheck needs under
current GitHub Actions runner load, with zero margin.
Impact
Any PR can be blocked from merging by a false-negative CI gate failure
that has nothing to do with the PR's own content, forcing a manual rerun
(possibly more than once) before a legitimately clean change can land.
Combined with the "CI gate" aggregate job (which correctly treats a
cancelled required job as not-a-pass), this can silently gate real work
on runner-speed variance.
Suggested fix
Increase static-analysis's timeout-minutes in .github/workflows/ci.yml
(currently 15) to give real headroom -- e.g. 20-25 minutes -- based on
observed near-ceiling runtimes on unrelated PRs.
Evidence
- Job 97852566480 (attempt 1): started_at 15:03:17Z, completed_at
15:18:27Z (15m10s), conclusion "cancelled", cppcheck's own last log line
before cancellation: "cppcheck: clean — zero findings".
- Job 97858198802 (attempt 2, same PR/diff): started_at 15:19:27Z,
completed_at 15:34:46Z (15m19s), conclusion "cancelled"; step-level
timing shows "Run cppcheck" ran 15:19:43Z-15:34:42Z (14m59s) with the
cppcheck process still running when terminated.
Summary
The
static-analysisjob'scppcheckstep timed out twice in a row on thesame PR (#591, no code changes between attempts) against its declared
timeout-minutes: 15:"clean — zero findings" at 117/117 files, then the job was cancelled
a fraction of a second later (
##[error]The operation was canceled.),total duration 15m10s.
Run cppcheckstep alone ran15:19:43Z → 15:34:42Z (14m59s) and was killed with the cppcheck process
still active (
Terminate orphan process: pid (2729) (cppcheck)).Both runs used the identical checked-out diff. This is not a one-off flake
in either the code or a single bad runner -- it's the job's 15-minute
budget being right at (or under) the actual time cppcheck needs under
current GitHub Actions runner load, with zero margin.
Impact
Any PR can be blocked from merging by a false-negative CI gate failure
that has nothing to do with the PR's own content, forcing a manual rerun
(possibly more than once) before a legitimately clean change can land.
Combined with the "CI gate" aggregate job (which correctly treats a
cancelled required job as not-a-pass), this can silently gate real work
on runner-speed variance.
Suggested fix
Increase
static-analysis'stimeout-minutesin.github/workflows/ci.yml(currently 15) to give real headroom -- e.g. 20-25 minutes -- based on
observed near-ceiling runtimes on unrelated PRs.
Evidence
15:18:27Z (15m10s), conclusion "cancelled", cppcheck's own last log line
before cancellation: "cppcheck: clean — zero findings".
completed_at 15:34:46Z (15m19s), conclusion "cancelled"; step-level
timing shows "Run cppcheck" ran 15:19:43Z-15:34:42Z (14m59s) with the
cppcheck process still running when terminated.