The `zombies` job had a job-level `timeout-minutes: 5` that covered a full
binary compile as well as the two scans it is meant to bound. On PRs that
change `go.sum` the Go cache is cold, the compile takes ~2m30s instead of
~29s, and the job exceeds 5 minutes even though the zombie check itself
passes. PR #5280 hit this on both attempts; #5273 passed with 19s to spare.
Build to `$RUNNER_TEMP` in a separate step and move `timeout-minutes` onto
the run step, so the 5-minute budget now measures only the scans (~1m42s)
and no longer depends on build speed. A step-level timeout also fails the
job rather than cancelling it, which is a clearer signal.
`smoke` had no timeout at all and inherited the 360-minute default despite
doing under a minute of work, so a hang in its live-verification scans
burned six hours of runner time. Both jobs now cap at 15 minutes to catch
build and infrastructure hangs.
Also set `cache: false` on setup-go in `checksecretparts`. That job is
stdlib-only and finishes in ~23s, so it wins the race to write the
`go.sum`-keyed cache and saves ~10MB with no module cache at all. Cache
keys are write-once, so every later job on the branch restores the empty
entry and cannot replace it.
Co-authored-by: Cursor <[email protected]>
