#!/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 "$@"