Page MenuHomePhabricator

Revisit how we run Selenium tests in our repos
Open, Needs TriagePublic

Description

I am frequently getting Wikibase Selenium failures on Vector. Usually these are due to race conditions and false positives. A recheck usually restores the problem but this wastes a lot of time in developer productivity and adds to CI traffic/slowdown.

As a consumer of these tests, there seems little value in running all browser tests on extensions and skins given we have a daily job that just does that. The only exception is for core changes, where I feel it is valuable to understand how a change there can impact extensions and skins.

Core: Run browser tests of all skins, core and extensions
Skins: Run browser tests of the skin.
Extensions: Run browser tests of the extension and all skins

Event Timeline

thcipriani subscribed.

The tests that we run for MediaWiki extensions and skins was @hashar's work 7 or 8 years ago; however, there is no one working on that currently. The workflow is implemented in Quibble so that's where to implement the change; however, developers should design what runs.

I believe this should be work shared between developers, platform, QTE, and our team providing instrumentation, but Release-Engineering-Team cannot make progress on this alone.

however, developers should design what runs.

Agreed, but my concern here is now what we run, but where we run the existing tests. Running all the tests for every repo delivers very little value IMO and slows down CI for everyone. I'd love to revisit this decision.

For example, as a Vector developer, I don't want Wikibase Selenium tests to run on every single patch there. The daily jobs are more than sufficient for catching those issues.