So yes, we're doing hacky dark magic there by literally overriding core Special:Undelete page with our own class. It's evil and so wrong in so many different ways but right now sadly the only solution. But what I don't get is why this hacky mess is causing some Selenium tests to fail when, AFAIK, the said tests were never set up for that repo to begin with?
Description
Event Timeline
@zeljkofilipin Pinging you here as per discussion on #wikimedia-releng. Thanks in advance for any and all insight you can provide into this!
In [[ https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/zuul/layout.yaml#6612 | zuul/layout.yaml#6612 ]], mediawiki/extensions/Video is set up to use extension-quibble template (defined in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/zuul/layout.yaml#967 | zuul/layout.yaml#967 ]]).
Out of all jobs defined in extension-quibble template, only quibble-vendor-mysql-hhvm-docker and mwgate-node10-docker Jenkins jobs run for Video.
quibble-vendor-mysql-hhvm-docker job (among other things) runs Selenium tests. Since Video has no other dependencies than mediawiki/core, only core's Selenium tests are executed. One of them (Page should be restorable, defined in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/tests/selenium/specs/page.js#118 | tests/selenium/specs/page.js#118 ]]) fails with:
An element could not be located on the page using the given search parameters ("#wpComment").
Looks like Video is doing something that makes the page not restorable. Test can not find element #wpComment (defined in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/tests/selenium/pageobjects/restore.page.js#4 | tests/selenium/pageobjects/restore.page.js#4 ]]).
To fix the problem, make sure the element is available. To run tests locally, see the documentation at Selenium/Node.js. Let me know if you have any questions.
@hashar might know more about how to resolve this problem on the CI side.
I showed @ashley how to access the build artifacts from Jenkins. In this case the test was correctly failing because MediaWiki was throwing an exception due to the patch.
Ah, I've forgot to take a look at the screenshots. I've assumed the extension just changed something. Good catch!