mirror of
https://github.com/discourse/discourse.git
synced 2026-08-05 18:46:18 +08:00
dbea1f184f`bin/qunit` could wait indefinitely for a headless browser that connected but then stopped making test progress, hanging the whole run with no useful diagnostics. This is most painful when the run was launched in an automated way, for example by an agent or in CI: a wedged headless Chrome blocks the caller with no signal, instead of returning a fast, diagnosable failure it can act on. This adds a browser watchdog that fails fast and identifies the reason instead of hanging. testem's native start timeout handles a browser that never connects, and a small testem patch handles one that connects but then goes idle outside an active test, reporting `Browser made no test progress for N seconds` on stderr and through the test result. There is deliberately no retry logic: on a stall the run exits non-zero so the caller that launched it can decide to retry the whole run. The watchdog is on by default and its two timeouts are configurable through flags and matching environment variables: `--browser-watchdog` / `QUNIT_BROWSER_WATCHDOG`, `--browser-start-timeout` / `QUNIT_BROWSER_START_TIMEOUT` (default 45s), and `--browser-inactivity-timeout` / `QUNIT_BROWSER_INACTIVITY_TIMEOUT` (default 30s). The CLI flag and environment wiring, including precedence over the environment, is covered by RSpec. The testem patch itself is not unit-tested, to avoid standing up a separate node test harness just to exercise another test harness. |
||
|---|---|---|
| .. | ||
| docker | ||
| annotaterb | ||
| bundle | ||
| dev | ||
| ember-cli | ||
| lint | ||
| notify_file_change | ||
| pitchfork | ||
| qunit | ||
| rails | ||
| rake | ||
| rspec | ||
| rubocop | ||
| system_rspec | ||
| turbo_rspec | ||
