Jdforrester-WMF added a comment.
In T279898#7028202 <https://phabricator.wikimedia.org/T279898#7028202>, @Addshore wrote: > So the current state would be: > > - Make mediawiki & extensions compatible with 2 versions of libraries > - Tests that use mediawiki-vendor will run using the old versions of the libraries > - Tests that do composer install will probably run using the newer version of the libraries > - Phan right now will always run using the older versions of the libraries (which can make such changes harder) > - I don't think there is anything in CI to actually make sure that the library changes in composer.json files are compatible with what is in mediawiki-vendor (see T179663 <https://phabricator.wikimedia.org/T179663>) > - Bump mediawiki-vendor versions, once everywhere can use the newer versions > - I don't think there are any checks to see if what is in the mediawiki-vendor composer.json actually lines up with what the other packages ask for (see T179663 <https://phabricator.wikimedia.org/T179663>) > - At this point Phan (and possibly other tests) can start to fail (as happened before this ticket was created) leading to broken main branches > - Fix the main branches / remove the back compat / remove the lower composer dependencies > - Everything is okay again > > I guess in this case the depends-on patches would be in the extensions etc on the bump to mediawiki-vendor? > Though it's hard to tell if they are needed as CI would be green at this point? Well, no. It's exceptionally rare, and not really supported, that multiple extensions have the same explicit dependency on something in vendor; certainly. You're making it far more complex than it should be, mostly because Wikibase is doing a bunch of things it's not meant to. You're meant to use MW's extension dependency system to depend on the extension that provides the composer dependency (in your case, Wikibase). Supporting multiple versions of composer libraries is not an expected outcome, except for people trying to support multiple versions of MediaWiki in the master branch (which is very heavily discourage and not actually supported by CI) or temporarily for transitional issues (like our support in core for two versions of dbal, because there's no version of dbal that supports both PHP 7.2 and 8.0). You're meant to: A) Write a patch in vendor that bumps the composer dependency. B) Write a patch in the extension that bumps the composer dependency and makes things work, dependent on (A). C) Merge them together. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/676077 should have depended on https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/676007 (not the other way around); that way, you would have been actually testing in CI the world that was going to happen once things merged. Of course, because WikibaseLexeme is not in the gate, at the end of the Wikibase patch landing WikibaseLexeme would have been broken, but merging https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/676419 would have then resulted immediately in a functioning world for everyone. (Had WikibaseLexeme been in the gate, you'd have needed to force-merge the Wikibase patch, which would have taken down CI for ~ an hour for everyone else, so…). I'd strongly recommend that you drop all of the `wikibase` composer dependencies from WikibaseLexeme //etc.//. They're all pulled in by Wikibase itself, and you actually care about those versions, as otherwise the code in Wikibase you're depending on will die. > In T279898#7027938 <https://phabricator.wikimedia.org/T279898#7027938>, @Jdforrester-WMF wrote: > >> The plan is to get phan fast enough that we can merge it into the regular `composer test` job in all repos, at which point it'll be covered everywhere equally. See T226945: Decide on future of running Phan tests on release branches <https://phabricator.wikimedia.org/T226945> for more details. > > I guess (but didn't check) that this would also solve the problem as jobs already exist doing composer test for mediawiki-vendor & composer install It would. > What ever happened to us offloading some of our CI workloads onto other cloudy providers? > That would make everything go much faster with very little effort > >> [2021-01-22 20:25:58] <addshore> James_F: mildly interesting, i ran a wmf-quibble-selenium-php72-docker job that had run on jenkins on github actions just to see what the test execution time was, 23 mins on jenkins, 16 mins on Github Actions https://usercontent.irccloud-cdn.com/file/0HH0fiSK/image.png The team made the decision to migrate to replace the current 'legacy' CI system (to GitLab, as you may have heard). Most of the effort is going into that, AIUI. The problem with the legacy CI is not infrastructure/speed, it's complexity and centralised control. Adding more centralised complexity will not make things better. TASK DETAIL https://phabricator.wikimedia.org/T279898 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jdforrester-WMF Cc: Krinkle, WMDE-leszek, hashar, Jdforrester-WMF, Tonina_Zhelyazkova_WMDE, Tarrow, Addshore, Aklapper, Invadibot, maantietaja, Mgagat, Akuckartz, Totolinototo3, Redabr4, Zanziii, Sadisticturd, Eladio.15, DannyS712, Nandana, A.S.Kochergin, Lahi, Gq86, Daimona, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
