You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
app/scripts/e2e-run-all-flows.sh runs each spec in a separate Appium session (Appium restarts per spec). With the single-Appium-session reset model introduced in tinyhumansai#1859, the all-flows runner is now duplicating session setup ~17 times per CI run. It should switch to one session for the whole suite, matching the design called out in app/test/wdio.conf.ts.
Problem
Current e2e-run-all-flows.sh:
run "test/e2e/specs/login-flow.spec.ts""login"
run "test/e2e/specs/auth-access-control.spec.ts""auth"
run "test/e2e/specs/telegram-flow.spec.ts""telegram"# … 17 specs, each via e2e-run-spec.sh → spins up Appium, mock server, CEF binary
Each run invocation calls e2e-run-spec.sh which calls e2e-run-session.sh which:
Cleans a temp workspace.
Launches CEF.
Waits for CDP.
Starts Appium.
Runs WDIO on the one spec.
Tears it all down.
That's ~30-60s of harness setup per spec × 17 specs = ~10 minutes of pure overhead per CI run.
Now that resetApp(<userId>) produces a fresh-install baseline in-place, all specs can share one session — just run wdio once over the whole specs/**/*.spec.ts glob (which wdio.conf.ts already targets).
Solution
Replace e2e-run-all-flows.sh with a single-session invocation: build once, launch CEF once, start Appium once, run wdio once over the full spec glob.
Per-spec failure isolation — WDIO's mocha.bail = 0 is already set; one failing spec must not stop the suite. Verify via a deliberately-failing canary spec.
Artifact collection — e2e/helpers/artifacts.ts already captures per-test failures; confirm they don't collide when many specs run back to back.
CI workflow — update whichever GitHub Actions job invokes the runner so it uses the new single-session script.
Acceptance criteria
Single-session runner — e2e-run-all-flows.sh (or a new e2e-run-suite.sh) runs all specs in one Appium session.
Suite runtime under 10min on CI — measured before/after; expect a 5-10× speedup for the harness-setup portion.
Spec independence enforced — resetApp(...) in every spec's before(); covered by a lint or grep CI check.
Per-spec failures are isolated — failing canary spec exits non-zero without killing later specs in the same session.
Artifact directories don't collide — each failure screenshot/source XML lives under its own per-run, per-test path.
Diff coverage ≥ 80% — shell script changes, exercised by running the runner in CI.
Summary
app/scripts/e2e-run-all-flows.shruns each spec in a separate Appium session (Appium restarts per spec). With the single-Appium-session reset model introduced in tinyhumansai#1859, the all-flows runner is now duplicating session setup ~17 times per CI run. It should switch to one session for the whole suite, matching the design called out inapp/test/wdio.conf.ts.Problem
Current
e2e-run-all-flows.sh:Each
runinvocation callse2e-run-spec.shwhich callse2e-run-session.shwhich:That's ~30-60s of harness setup per spec × 17 specs = ~10 minutes of pure overhead per CI run.
Now that
resetApp(<userId>)produces a fresh-install baseline in-place, all specs can share one session — just runwdioonce over the wholespecs/**/*.spec.tsglob (whichwdio.conf.tsalready targets).Solution
e2e-run-all-flows.shwith a single-session invocation: build once, launch CEF once, start Appium once, runwdioonce over the full spec glob.resetApp(...)inbefore()with a uniqueuserId. Audit + add as part of the spec-conversion sweep (Convert RPC-heavy E2E specs to drive the UI past login tinyhumansai/openhuman#1860).mocha.bail = 0is already set; one failing spec must not stop the suite. Verify via a deliberately-failing canary spec.e2e/helpers/artifacts.tsalready captures per-test failures; confirm they don't collide when many specs run back to back.Acceptance criteria
e2e-run-all-flows.sh(or a newe2e-run-suite.sh) runs all specs in one Appium session.resetApp(...)in every spec'sbefore(); covered by a lint or grep CI check.Related