ci: stop a hung step from costing an afternoon - #47
Conversation
The quality job on 3ebd3df sat for eighty minutes and reported nothing. It was not a test failure: `apt-get` never returned, gates.sh never ran, and the job was killed before it could upload a log, so the only evidence left was a step stuck in_progress with no end timestamp. That apt-get was buying nothing. ubuntu-latest ships jq preinstalled, and the step's own output said so on every run that got that far -- "jq is already the newest version". It was a network dependency taken out on behalf of a package we already had, and it could only ever cost us. Bounding each job matters more than removing the one step that hung, since any step can stall. The limits are near ten times observed runtime, which is far too loose to interrupt real work and tight enough that the next stall reports a failure while someone is still watching.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe CI workflow adds explicit timeouts to quality, cross-platform, dependency-audit, and supply-chain jobs. The quality job removes its ChangesCI controls
Estimated code review effort: 1 (Trivial) | ~3 minutes Merge Risk: ⚪ Minimal · up to The change removes the hanging package-install step and adds bounded job timeouts; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Follow-up to #46. That PR fixed the advisory; this fixes the thing that made the same run take eighty minutes to tell us nothing.
What happened
On
3ebd3dfthequalityjob ran for 1h20m and failed. It was not a test failure — the step timings show it never got as far as the tests:apt-gethung,gates.shnever ran, and the job was killed before it could upload a log — so the run reported no reason at all. A re-run of the identical tree passedqualityin 2m19s.Two changes
The apt-get is gone.
ubuntu-latestships jq preinstalled, and this step said so itself on every run that got far enough to print it:It installed nothing and took out a network dependency on our behalf.
gates.shgenuinely needs jq (10 call sites), so the comment left behind records why we now rely on the image providing it — and if a future image drops it,gates.shfails withjq: command not foundimmediately rather than stalling.Every job is bounded. Removing the step that hung this time does not stop the next step from hanging; the missing guard was the real defect. Limits are roughly ten times observed runtime — loose enough never to interrupt real work, tight enough that a stall fails while someone is still watching:
qualitycross-platformdependency-auditsupply-chainValidation
.github/workflows/ci.ymlparses and all four jobs carry a limit with noapt-getremaining. The diff is 13 added lines and 1 removed — no job logic, ordering, or toolchain pin is touched, so this run of CI is itself the test.Summary by CodeRabbit