This is "expected" behaviour in the sense that we document this failure mode in the code:

This task is similar to T226869, though I might take a different approach here.

@Sarai-WMDE Thanks so much for the feedback! I implemented the grid fix in this patch and will wait to see if someone files a follow-up.

That config patch has been merged now. @hashar could you give the original patch another shot at some point? Thanks!

Per my comment on the patch, I think this change needs to depend on I73f465d86eafc377ad69c5054404673108c3f182. $wgEntitySchemaIsRepo = false; needs to be set in the CI setup, otherwise these service wiring errors will show.

@Arian_Bozorg Any thoughts from your side about how best to proceed here? Is this is design question? Or should I just duct-tape over it for now so that it works?

This looks like an almost identical failure to the failure in T368369. I think it might make sense at least for the Minerva tests to set the content language in test setup if we're going to make assertions about localised page names.

Had a quick look at this today. The change @Lucas_Werkmeister_WMDE identified does indeed trigger the issue. I'm not sure what the solution here should be though.

Made a patch to address specifically the issue of errors from the AbuseFilter (or other EditFilterMergedContent hooks) for new entity schemas. If we want to fix other error messages, let's file a ticket that details which and under what circumstances they show up.

The tool is offline now:

The patches have reduced the runtime by over three minutes:

This is now unblocked - the pending change (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TwoColConflict/+/1048824) has been merged. We can revisit enabling parallel testing for TwoColConflict in the future, but since all jobs run in under 7 mins, it doesn't seem an urgent priority.

Thank you! and good to know. Will ask them in future.

@Jdforrester-WMF Could you please publish the new version to NPM for us?

Ah - yes. That's definitely my bad. It needs a file-exists check, but I didn't get to adding that. I'll take a look - thanks for the report!

Tagging T361190 here as this is a failure that was surfaced by parallel testing

This looks like it might be related to test ordering. From my experiments locally, extensions/WikibaseLexeme/tests/phpunit/mediawiki/Api/EditFormElementsTest.php passes fine when its run alone, and fails if it's run in a suite with extensions/AbuseFilter/tests/phpunit/integration/Hooks/ConfirmEditHandlerTest.php:

By way of validation, I did a couple of test runs comparing the .phpunit.results.cache files between the linear and parallel execution and found no difference in the tests executed:

@thcipriani since the migration to GitLab seems to be postponed (indefinitely?) can we reopen this ticket?