Part of #11573 (split from it). Checks were stopped at 16.1–18.0 of 16 cores because the suite starts more parallel work than its cell has cores (the busiest process was sh, ~500 s of CPU).
Done looks like:
[ ] src/checks/service.ts passes the cell's cores (resolveLimits("step", manifest.limits).cpus, already read as cellCpus) to the check command in one environment variable (e.g. FORGE_CHECK_CPUS), and the forge's own gate (scripts/gate.ts) caps its shards/workers at that number when it is set.
[ ] A test asserts the variable is set on the step's environment and that the gate's worker count for FORGE_CHECK_CPUS=4 is at most 4.
[ ] Only src/checks/service.ts, scripts/gate.ts and one new test change; if scripts/gate.ts lists tests by hand, the new test is listed there in the same commit.
[ ] Run that test and bun x tsc --noEmit before the push; do not run the whole suite in the sandbox.
Part of #11573 (split from it). Checks were stopped at 16.1–18.0 of 16 cores because the suite starts more parallel work than its cell has cores (the busiest process was
sh, ~500 s of CPU).Done looks like:
src/checks/service.tspasses the cell's cores (resolveLimits("step", manifest.limits).cpus, already read ascellCpus) to the check command in one environment variable (e.g.FORGE_CHECK_CPUS), and the forge's own gate (scripts/gate.ts) caps its shards/workers at that number when it is set.FORGE_CHECK_CPUS=4is at most 4.src/checks/service.ts,scripts/gate.tsand one new test change; ifscripts/gate.tslists tests by hand, the new test is listed there in the same commit.bun x tsc --noEmitbefore the push; do not run the whole suite in the sandbox.