https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/ fails since Nov 9th 3:20am UTC
/usr/local/bin/wmf-beta-update-databases.py yields:
/usr/local/bin/mwscript update.php --wiki=aawiki --quick #!/usr/bin/env php MediaWiki 1.29.0-alpha Updater oojs/oojs-ui: 0.18.0 installed, 0.17.10 required. Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies
I guess mediawiki/vendor has not been updated.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/vendor | master | +231 -437 | Revert "Update OOjs UI to v0.18.0" | |
| mediawiki/core | master | +0 -0 | (DO NOT SUBMIT) test for QUnit/OOjs |
MediaWiki core composer.json has:
"oojs/oojs-ui": "0.17.10",
https://gerrit.wikimedia.org/r/#/c/320557/ bumped oojs-ui in mediawiki/vendor to v0.18.0
MediaWiki core change is https://gerrit.wikimedia.org/r/#/c/320558/ That fails the VisualEditor qunit tests though:
10:49:07 Chrome 53.0.2785 (Linux 0.0.0) ve.ui.MWWikitextStringTransferHandler convert FAILED 10:49:07 Simple reference: triggers match function 10:49:07 Expected: "wikitextString" 10:49:07 Actual: "plainTextString" 10:49:07 at runWikitextStringHandlerTest
test.mediawiki.qunit.testrunner Loader status FAILED 00:03:37.264 Modules in error state 00:03:37.264 Expected: [] 00:03:37.264 Actual: [ 00:03:37.264 "ext.cite.visualEditor", 00:03:37.264 "ext.cite.visualEditor.test" 00:03:37.264 ]
I have no idea why the change to mediawiki/vendor ( https://gerrit.wikimedia.org/r/#/c/320557/ ) passed just fine. The failure might be somewhere else..
Change 320576 had a related patch set uploaded (by Hashar):
(DO NOT SUBMIT) test for QUnit/OOjs
Mentioned in SAL (#wikimedia-operations) [2016-11-09T11:17:40Z] <hashar> CI gate for MediaWiki fails tests. On it. See https://phabricator.wikimedia.org/T150323
@hashar visualeditor is using oojs ui 0.17.0 so that may be because it fails.
See open patch https://gerrit.wikimedia.org/r/#/c/320553/
Change 320579 had a related patch set uploaded (by Paladox):
Revert "Update OOjs UI to v0.18.0"
Change 320576 abandoned by Hashar:
(DO NOT SUBMIT) test for QUnit/OOjs
Reason:
Fixed by reverting OOJS
Change 320579 abandoned by Hashar:
Revert "Update OOjs UI to v0.18.0"
Reason:
Redid with https://gerrit.wikimedia.org/r/#/c/320580/ which is linked on the original change and point to the task :)
Mentioned in SAL (#wikimedia-operations) [2016-11-09T12:14:23Z] <hashar> CI gate for MediaWiki is back. Reverted an oojs-ui version bump that triggered tests failure but was not caught properly by CI. T150323
Argh. @Volker_E merged https://gerrit.wikimedia.org/r/#/c/320557/ but not https://gerrit.wikimedia.org/r/#/c/320558/ which has (as always) the absolutely catastrophic effects of breaking everything about MediaWiki. Sorry, everyone.
@Jdforrester-WMF Hi, it failed the qunit tests https://integration.wikimedia.org/ci/job/mediawiki-extensions-qunit-jessie/15824/console
Repeating from the patch: That was a troubled evening yesterday and my Internet stopped unexpectedly working before I could look into the other changes. And then it got even worse. Also didn't expect to be the only one reviewing it. I'm very sorry!
@Volker_E no worries! We caught it fast enough and the fix was quite easy (just press the revert button).
What I am wondering now is why CI does not fail completely when one propose such a change to mediawiki/vendor. That is probably intentional to avoid a dependency loop between /core and /vendor. I never quite looked at how the dependencies are bumped and how CI react.
I am also wondering why we have oojs-ui included both in /core and /vendor. I bet it is because it is needed by the Mw installer. Maybe we can stop including it in mediawiki/vendor ?
Indeed. :-)
What I am wondering now is why CI does not fail completely when one propose such a change to mediawiki/vendor. That is probably intentional to avoid a dependency loop between /core and /vendor. I never quite looked at how the dependencies are bumped and how CI react.
Yes.
I am also wondering why we have oojs-ui included both in /core and /vendor. I bet it is because it is needed by the Mw installer. Maybe we can stop including it in mediawiki/vendor ?
It's in /vendor because it's a PHP library and so "must" be loaded there via composer, apparently. Personally I'd much prefer it to be in the /core repo only but we were told no.