Browser tests: run on two processes

tiagoagueda commented

2026-10-04 20:43:13 +00:00

Owner

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes two jobs at a time, in the order the workflow file lists them, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict.

The browser suite runs in one process. Nothing in it needs that: pytest-django gives each xdist worker its own live server on its own port and its own in-memory database, the media, log and static directories are a temporary directory per process (settings/test.py:37-66), and #294's connection registry is per process. pytest-xdist is already installed in the browser job.

Proposal

-n 2 --dist worksteal on CI; -n 4 is fine on a desktop. Two, because the other slot runs the unit suite on the same six-core host (#233 is what -n auto did to it).
worksteal rather than loadfile: no browser test shares a database fixture with another, and loadfile would put all of test_board_fold.py on one worker.
The long walks are collected first, so no worker is left holding an 80-second walk at the end.
The main run writes no artifacts once failures are re-run alone with tracing on, so pytest-playwright clearing its output folder once per worker stops mattering.

Done when

The browser job runs on two workers and its test step takes about half as long.

Measured from Forgejo's task API and job logs, runs 561–710 (24 Sep – 4 Oct 2026): wall time per push about 52–55 min, up from about 15; the browser suite grew from 149 to 645 tests in five days and runs serially (29 min); the runner takes **two jobs at a time, in the order the workflow file lists them**, so the browser job starts 19–22 min after the push; and Forgejo cancels the older push run when a newer push lands, which stopped 18 of 56 browser jobs before they gave a verdict. The browser suite runs in one process. Nothing in it needs that: pytest-django gives each xdist worker its own live server on its own port and its own in-memory database, the media, log and static directories are a temporary directory per process (`settings/test.py:37-66`), and #294's connection registry is per process. pytest-xdist is already installed in the browser job. ## Proposal - `-n 2 --dist worksteal` on CI; `-n 4` is fine on a desktop. Two, because the other slot runs the unit suite on the same six-core host (#233 is what `-n auto` did to it). - `worksteal` rather than `loadfile`: no browser test shares a database fixture with another, and `loadfile` would put all of `test_board_fold.py` on one worker. - The long walks are collected first, so no worker is left holding an 80-second walk at the end. - The main run writes no artifacts once failures are re-run alone with tracing on, so pytest-playwright clearing its output folder once per worker stops mattering. ## Done when - The browser job runs on two workers and its test step takes about half as long.

tiagoagueda added the

enhancement

label

2026-10-04 20:43:13 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 22:21:24 +00:00

Run the browser tests on two processes, the walks of every page first

tiagoagueda closed this issue

2026-10-04 22:21:24 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 23:41:37 +00:00

Run the browser tests on one process again, and log the host's load