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
53 lines
2.1 KiB
Bash
Executable File
53 lines
2.1 KiB
Bash
Executable File
#!/bin/sh
|
|
# script/test: run the test suite.
|
|
#
|
|
# jest runs three worker processes (package.json), not one per CPU core: on a
|
|
# many-core shared host one per core took gigabytes of RAM per run.
|
|
#
|
|
# The timeout bounds a hung suite; it is not a performance budget. On the busy
|
|
# shared build host the suite takes 23-29s with three workers, so
|
|
# REPO_POLICIES' 30s cap is tight there, not comfortable. Inside the image the
|
|
# same suite also pays a cold jest cache and shares the runner with the rest of
|
|
# the build, which is not what that budget describes, so the Dockerfile raises
|
|
# the bound through AUTISTMASK_TEST_TIMEOUT. A cap a healthy suite can trip on a
|
|
# cold cache produces a red that means nothing, and teaches "just run it again".
|
|
set -eu
|
|
|
|
ROOT="$(cd "$(dirname "$0")/.." && pwd -P)"
|
|
TIMEOUT="${AUTISTMASK_TEST_TIMEOUT:-30}"
|
|
|
|
main() {
|
|
cd "$ROOT"
|
|
echo "Running tests (timeout ${TIMEOUT}s)..."
|
|
|
|
status=0
|
|
timeout "$TIMEOUT" yarn run test 2>&1 || status=$?
|
|
[ "$status" -eq 0 ] && return 0
|
|
|
|
# 124 is timeout(1) killing the suite. Say so: a kill is not a failed
|
|
# assertion, and the verbose rerun would only spend the same wall clock
|
|
# to be killed again.
|
|
if [ "$status" -eq 124 ]; then
|
|
echo "tests: TIMED OUT after ${TIMEOUT}s (no assertion failed)" >&2
|
|
echo "tests: raise AUTISTMASK_TEST_TIMEOUT if the suite is healthy" >&2
|
|
exit 1
|
|
fi
|
|
|
|
# 125 is timeout(1) itself failing, which here means AUTISTMASK_TEST_TIMEOUT
|
|
# is not a duration it accepts. The suite never ran, so it neither timed out
|
|
# nor failed, and the verbose rerun would only reprint the same complaint.
|
|
if [ "$status" -eq 125 ]; then
|
|
echo "tests: DID NOT RUN: timeout(1) rejected AUTISTMASK_TEST_TIMEOUT=\"${TIMEOUT}\"" >&2
|
|
echo "tests: set it to a duration such as 30 or 180 (see timeout(1))" >&2
|
|
exit 1
|
|
fi
|
|
|
|
echo "--- Rerunning with --verbose for details ---"
|
|
timeout "$TIMEOUT" yarn run test:verbose 2>&1 || true
|
|
# Always fail: the first run already proved the tests are broken, so a
|
|
# flaky pass on the rerun must not turn the build green.
|
|
exit 1
|
|
}
|
|
|
|
main "$@"
|