Repository navigation
perf(ci): parallelize browser regressions and report phase timings - #382
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Browser regression currently runs Chromium and WebKit sequentially with one worker, taking 38–46 minutes in recent successful jobs. Run two Chromium shards and two duration-balanced WebKit groups (Lottie / all other suites) on independent runners. Preserve one worker per runner and the existing WebKit process isolation.
Keep
browser-regressionas the aggregate required check. It only succeeds when static checks and every browser group succeed; failed, cancelled and skipped prerequisites cannot pass the gate. Cancel superseded runs for the same PR/ref and retain per-group reports and failure artifacts for seven days.Add a timing reporter with setup/body/teardown breakdowns, slow-file summaries and machine-readable results. Tooling tests discover the real Playwright suites to verify that the workflow groups cover every case exactly once: both Chromium shards and both WebKit groups, including the newly merged Brush cases. Local commands still run the full suites by default. No test assertions, retries or per-test timeouts are relaxed.
Collaboration replicas now initialize only the canvas they use. The main page and all canvas-isolation/lifecycle scenarios retain both canvases. This avoids two unused WebGL contexts across the additional tabs; locally the Yjs case improved from exceeding its 30-second limit to ~20 seconds.
Validation:
The previous CI log puts WebKit Lottie at ~11.6 minutes and the remaining WebKit cases at a similar cost. The target is approximately 15 minutes overall with available runners; actual CI timing is not yet measured.