Repository navigation
CI: scale fork timeouts to the runner a fork actually gets - #112
Conversation
Every CI run in this fork is cancelled, and has been since at least
August, including runs on `main`. None of them is a test result: the
jobs are killed at their `timeout-minutes` while still compiling.
The cause is visible in the workflow itself. Each of these jobs already
picks its runner per repository, and then applies a budget calibrated
for the machine only upstream receives:
cargo test (linux) depot-ubuntu-22.04-16 -> ubuntu-latest, 20 min
cargo test (windows) ...-16x32 -> windows-latest, 20 min
Build ty depot-ubuntu-22.04-32 -> ubuntu-latest, 5 min
A fork drops to roughly a quarter of the cores in the first two cases
and an eighth in the third, with the limit unchanged. The Build ty job
is the starkest: five minutes for a cold build of the whole workspace
on a four-core runner.
The repository already knows the shape of this fix — the fuzz job's
budget reads `github.repository == 'astral-sh/ruff' && 10 || 20`. This
applies that same expression to the three jobs that lack it, and raises
the fuzz job's own fork value, which was fork-aware but still short
(it was cancelled at 20 minutes in the run that prompted this).
Nothing upstream changes: every expression keeps the current value on
the `astral-sh/ruff` side.
The fork-side numbers are estimates from the core-count ratio, not
measurements — a suite that has never completed here cannot tell me
what it needs, and this machine cannot build the workspace to find
out. They are deliberately generous rather than tight; if a run now
completes well inside the budget, tighten it against that measurement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughCI workflow jobs now use repository-dependent timeouts. Upstream jobs keep shorter limits, while fork jobs receive longer limits for Cargo tests, fuzzing, and ChangesCI timeout adaptation
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to CI timeout budgets now allow slower fork runners more time while preserving upstream limits. The configured selectors align with the runner selection logic, with no remaining merge-readiness risk identified. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_abdda3ec-7dcc-44d0-8856-fd6b6a4ebce5) |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
The first pass raised three jobs to budgets picked without evidence, because every affected job was being cancelled before it could report a duration. One green run now supplies the numbers: cargo test (linux) 22m04s, windows-latest 24m36s, macos-latest 14m45s, the ty fuzzer 15m14s, a ty build 5m34s. Each fork budget drops to roughly twice its observed cost. The same run also cancelled `ecosystem` at 20m27s. It has the identical shape -- an 8-core Depot runner upstream, ubuntu-latest on a fork, one timeout for both -- and was missed in the first pass. Its budget is deliberately looser than the others: the cancellation proves it needs more than 20 minutes without saying how much more. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_32186512-6593-4c2c-8102-6168e7a9f2d7) |
Every CI run in this fork is cancelled, and has been since at least August, including runs on
main. None of them is a test result — the jobs are killed at theirtimeout-minuteswhile still compiling.The cause is visible in the workflows themselves. Each of these jobs already selects its runner per repository, then applies a budget calibrated for the machine only upstream receives:
cargo test (linux)depot-ubuntu-22.04-16ubuntu-latestcargo test (windows)...-windows-2022-x86-64-16x32windows-latestecosystemdepot-ubuntu-24.04-8ubuntu-latestBuild tydepot-ubuntu-22.04-32ubuntu-latestA fork drops to roughly a quarter of the cores in the first two cases and an eighth in the last, with the limit unchanged.
Build tyis the starkest: five minutes for a cold build of the whole workspace on a four-core runner.The repository already knows the shape of this fix — the fuzz job's budget reads
github.repository == 'astral-sh/ruff' && 10 || 20. This applies the same expression to the four jobs that lack it, and raises the fuzz job's own fork value, which was fork-aware but still short: it was cancelled at twenty minutes in the run that prompted this.Nothing upstream changes. Every expression keeps its current value on the
astral-sh/ruffside.The fork budgets are now measured, not estimated
The first commit raised three jobs to values derived from the core-count ratio, because a suite that has never completed cannot say what it needs. The run on that commit is the first green CI this fork has had, and it supplies the numbers. The second commit replaces every guess with roughly twice the observed cost:
cargo test (linux)cargo test (windows-latest)cargo test (macos-latest)Fuzz for new ty panicsBuild tyrust-cache)ecosystemcargo test (linux)is the only required job and the one that gatesall required checks passed; both are green.Two honest caveats.
Build tywas measured with a warm cache, so its budget carries room for a cold one — the case five minutes could never have survived. Andecosystemhas no completion time: it was missed in the first pass despite having the identical shape, and its cancellation proves only that it needs more than twenty minutes, not how much more. Its 45 is deliberately the loosest number here and is the one still worth tightening against a future green run.https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V