In theory it is simple as adding --parallel to the api-testing command definition in package.json. In practice, some of the setup code will need adjustment.
|Open||None||T225730 Reduce runtime of MW shared gate Jenkins jobs to 5 min|
|Open||None||T298735 Run api-testing tests in parallel|
|Open||None||T199393 Reproducible deadlock in User::addToDatabase() when api.php?action=createaccount is called simultaneously by several users|
Running the core api-testing tests in parallel works (see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/752994), however due to T199393: Reproducible deadlock in User::addToDatabase() when api.php?action=createaccount is called simultaneously by several users, mw-error.log is not empty and so the assert-no-mediawiki-errors macro fails.
The code in api-testing is set to ignore these exceptions and retry the account creation process. But those errors are written to the logs anyway, see https://integration.wikimedia.org/ci/job/mediawiki-quibble-apitests-vendor-php72-docker/25346/console. Some options:
- disable this macro for any api-testing job (or just the core one)
- modify the macro to not through an error if the only exception is the "Deadlock found when trying to get lock". That's tricky, because the errors are written in multiple lines with stacktraces, but I guess not impossible to do with a scripting language. You'd need some code to find the start and end of the stacktrace containing "Deadlock found when trying to get lock", remove those lines from the log file, and then assert that the log file is empty at the end.
The proper fix for this would be to fix the back-end to not instantly throw an error on deadlock but instead pause a little (rather than retrying at the browser test level)?
I'd be against dropping or modifying the clean-error-logs macro, as we put so much effort into cleaning up the code to get it to pass the first two times. Not running the macro for the browser tests feels very risky for missing things.