This is a Test Platform initiative to get the feedback loop for changes pushed to mediawiki/core down to below ten minutes. That means you as a developer will know whether your patch passed or failed within ten minutes of submitting it.

The goal is to reduce feedback time without sacrificing test coverage or quality. We want faster results, not fewer checks. The goal is to have the median for the jobs to be under ten minutes.

Background

Fast CI feedback loop matters because it directly affects how developers work. When results take too long, developers context-switch to other tasks, lose track of what they were doing. The longer the wait, the more costly a failure becomes.

Prior art at T225730: Reduce runtime of MW shared gate Jenkins jobs to 5 min

Status before the initiative

Here's an example of a patch sent to core the 28th of January 2026. At the moment the time for different jobs looked like this:

The longest running job decides the feedback time. At that time, it was the quibble-with-gated-extensions-selenium job at 24 minutes and 4 seconds.

Numbers from January (excluding failures and cache hits, use this link to calculate without failures and cache hits):

Developer feedback loop time, showing the median time a developer needs to wait to get feedback (using this query):

The plan

We plan to work on a couple of different areas to bring feedback time under 10 minutes.

Make webdriver.io tests in core and wdio-mediawiki faster

In core we have a webdriver.io npm package that we publish and use when we run tests in core, extension and skins. We should focus on making that as fast as possible, because that will make the core specific webdriver.io test faster and also affect the tests that runs in our slowest job (the gated extensions job). It will also make all jobs that runs in CI faster that use the package, potentially decrease the load on CI. The plan for this work is:

1. Decrease the CPU usage for the current tests
2. Use the decreased CPU usage by running more tests in parallel
3. Utilize the parallelization and make sure we run test as fast as possible

The work is tracked in T417130.

Make the gated extension browser test job faster

Our slowest test needs to be faster. The plan is:

1. Utilize the changes in wdio-mediawiki by updating all extensions/skins that runs in this job
2. Move the slowest running jobs to separate jobs (at the moment the focus is Wikibase and GrowthExperiment).
3. Utilize the parallelization in each extension/skin and make sure we run test as fast as possible

The work is tracked in T421476 and most work in T417130 also contribute to this goal.

Increase the speed of the jobs that sometimes are slower than 10 minutes

There are a couple of jobs that are sometimes faster and sometimes slower than 10 minutes. These jobs needs to be faster than 10 minutes all the time. Focus on one job at a time.

quibble-with-gated-extensions-vendor-mysql-php83

Plan to be decided. Tracked in T420879

quibble-for-mediawiki-core-vendor-mysql-php83

Plan to be decided. The first thing to do is to test to run the phpunit tests in parallel in Quibble. Work tracked in T420880.

Jobs that are moved from the gated extension job. Potentially a specific Wikibase and GrowthExperiment job.

Wikibase uses wdio-mediawiki, so when it uses the latest version, it can use parallelization. Work tracked in T420882.

Extra

The CI upgrade in T421114 will also contribute to faster CI times (updated software and two more CPUs per CI instance).

Risks and mitigations

These jobs include tests that are moving targets. Teams continuously add and update tests alongside our work. That's expected and welcome, but it means we need to make sure new tests follow the patterns and practices we introduce (such as parallelization), so we don't regress on feedback time.