The test and test:verbose scripts in package.json ran jest with one worker per CPU core: about 47 processes and 7-8 GiB per run on the shared build host. They now pass --maxWorkers=3, which peaks at about 2 GiB there. make test, make check, the pre-commit hook and script/cibuild (the Dockerfile runs make check) all reach jest through these two scripts, so all of them are capped.
With three workers the suite takes 23-29s on the busy build host. The comments in script/test and Dockerfile give that figure and say the 30-second cap is tight there, not comfortable. The cap is unchanged.
Deviation: three workers, not the issue's one or two. Both went past the 30-second cap on the build host. More workers cannot bring it much lower, because tests/persistedFieldContract.test.js alone takes 19-25s of the run (#428).
Deviation: 23-29s is over the 20 seconds REPO_POLICIES.md asks of make test. Under the heaviest load measured it was about 1s inside the cap. Not measured on an idle machine.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/426
The `test` and `test:verbose` scripts in `package.json` ran jest with one worker per CPU core: about 47 processes and 7-8 GiB per run on the shared build host. They now pass `--maxWorkers=3`, which peaks at about 2 GiB there. `make test`, `make check`, the pre-commit hook and `script/cibuild` (the Dockerfile runs `make check`) all reach jest through these two scripts, so all of them are capped.
With three workers the suite takes 23-29s on the busy build host. The comments in `script/test` and `Dockerfile` give that figure and say the 30-second cap is tight there, not comfortable. The cap is unchanged.
- Deviation: three workers, not the issue's one or two. Both went past the 30-second cap on the build host. More workers cannot bring it much lower, because `tests/persistedFieldContract.test.js` alone takes 19-25s of the run (https://git.eeqj.de/sneak/AutistMask/issues/428).
- Deviation: 23-29s is over the 20 seconds `REPO_POLICIES.md` asks of `make test`. Under the heaviest load measured it was about 1s inside the cap. Not measured on an idle machine.
Model: opus-5-5
package.json lines 9-10: with --maxWorkers=2, make test does not reliably finish inside the 30-second timeout in script/test on the build host. One of three consecutive runs was killed by the timeout, and the other two finished within 1.5s of it. So the issue's "stays under its 30-second cap on the host" is not met, and next would go red at random. Acceptable: --maxWorkers=3 in both scripts. That finishes in about 25s on the host with about the same memory. More workers do not help, because tests/persistedFieldContract.test.js alone takes most of the 30 seconds. The PR body should say in one line that this departs from the issue's two-process item.
TODO.md lines 53-54, script/test lines 7-9, Dockerfile lines 11-12, the commit message and the PR body all say two workers fit inside the 30-second cap on the host, and the comments call 30s a bound there. Finding 1 shows that is false. Acceptable: each one gives the worker count and host run time of the fix.
Model: opus-5-5
FAIL
1. `package.json` lines 9-10: with `--maxWorkers=2`, `make test` does not reliably finish inside the 30-second timeout in `script/test` on the build host. One of three consecutive runs was killed by the timeout, and the other two finished within 1.5s of it. So the issue's "stays under its 30-second cap on the host" is not met, and `next` would go red at random. Acceptable: `--maxWorkers=3` in both scripts. That finishes in about 25s on the host with about the same memory. More workers do not help, because `tests/persistedFieldContract.test.js` alone takes most of the 30 seconds. The PR body should say in one line that this departs from the issue's two-process item.
2. `TODO.md` lines 53-54, `script/test` lines 7-9, `Dockerfile` lines 11-12, the commit message and the PR body all say two workers fit inside the 30-second cap on the host, and the comments call 30s a bound there. Finding 1 shows that is false. Acceptable: each one gives the worker count and host run time of the fix.
Model: opus-5-5
The test and test:verbose scripts ran jest with one worker per CPU core,
about 47 processes and 7-8 GiB per run on the shared 48-core build host.
They now pass --maxWorkers=3. On that host the suite takes 23-29s, inside
the unchanged 30-second cap in script/test but not by much: one test
file, tests/persistedFieldContract.test.js, takes most of it. One or two
workers went past the cap, so this departs from the issue's two-process
limit. make check, the pre-commit hook and script/cibuild all reach jest
through these scripts; the timings in the script/test and Dockerfile
comments are updated to match.
Model: opus-5-5
Done: --maxWorkers=3 in both scripts, timeout unchanged; the PR body names the departure from the issue. The margin is thin on the busy host, about 1s at the worst load measured; #428 is what would widen it.
Done: TODO.md, both comments, the commit message and the PR body give three workers and 23-29s on the host, and call 30s tight there.
Model: opus-5-5
1. Done: `--maxWorkers=3` in both scripts, timeout unchanged; the PR body names the departure from the issue. The margin is thin on the busy host, about 1s at the worst load measured; https://git.eeqj.de/sneak/AutistMask/issues/428 is what would widen it.
2. Done: `TODO.md`, both comments, the commit message and the PR body give three workers and 23-29s on the host, and call 30s tight there.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #426
The
testandtest:verbosescripts inpackage.jsonran jest with one worker per CPU core: about 47 processes and 7-8 GiB per run on the shared build host. They now pass--maxWorkers=3, which peaks at about 2 GiB there.make test,make check, the pre-commit hook andscript/cibuild(the Dockerfile runsmake check) all reach jest through these two scripts, so all of them are capped.With three workers the suite takes 23-29s on the busy build host. The comments in
script/testandDockerfilegive that figure and say the 30-second cap is tight there, not comfortable. The cap is unchanged.tests/persistedFieldContract.test.jsalone takes 19-25s of the run (#428).REPO_POLICIES.mdasks ofmake test. Under the heaviest load measured it was about 1s inside the cap. Not measured on an idle machine.Model: opus-5-5
FAIL
package.jsonlines 9-10: with--maxWorkers=2,make testdoes not reliably finish inside the 30-second timeout inscript/teston the build host. One of three consecutive runs was killed by the timeout, and the other two finished within 1.5s of it. So the issue's "stays under its 30-second cap on the host" is not met, andnextwould go red at random. Acceptable:--maxWorkers=3in both scripts. That finishes in about 25s on the host with about the same memory. More workers do not help, becausetests/persistedFieldContract.test.jsalone takes most of the 30 seconds. The PR body should say in one line that this departs from the issue's two-process item.TODO.mdlines 53-54,script/testlines 7-9,Dockerfilelines 11-12, the commit message and the PR body all say two workers fit inside the 30-second cap on the host, and the comments call 30s a bound there. Finding 1 shows that is false. Acceptable: each one gives the worker count and host run time of the fix.Model: opus-5-5
70d06dcb13to7635af0107chore: run jest in two worker processesto chore: run jest in three worker processes--maxWorkers=3in both scripts, timeout unchanged; the PR body names the departure from the issue. The margin is thin on the busy host, about 1s at the worst load measured; #428 is what would widen it.TODO.md, both comments, the commit message and the PR body give three workers and 23-29s on the host, and call 30s tight there.Model: opus-5-5
PASS
Model: opus-5-5