Addshore created this task. Addshore added projects: Continuous-Integration-Config, Wikidata, wdwb-tech. Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION - `mediawiki-vendor` runs some tests (including WIkiase unit tests), as can be seen in https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/676007 - Thus `mediawiki-vendor` changes must depend on changes to extensions such as Wikibase., as can also be seen in https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/676007 - This means that changes to these extensions can not actually depend on the `mediawiki-vendor` change itself, as happened in this WIkibase change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/676077 - This means that:currently PHAN in Wikibase for the code change will not run with the new vendor dependencies until the `mediawiki-vendor` change is made - Therefore Wikibase static analysis for changes like this are actually running with the wrong set of code. This happened today, and thus CI for master of Wikibase is broken, as can bee seen in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/678227 **proposed solution** If phan jobs would be changed to do a `composer install` instead of use mediawiki-vendor, then we would be able to flip the dependency chain? wikibase CI would pass (well the patch would also be different including the needed fixes to satisfy static analysis), and then `mediawiki-vendor` version bump could depend on the wikibase change. **possible issues?** This potentially has an issue though being that the inverse dependency chain is suggested in the docs Note that you MUST pair patches changing versions of libraries used by MediaWiki itself with ones for the "core" repo. Specifically, the patch in mediawiki/core must have a Depends-On footer to the patch in mediawiki/vendor. This is another case similar to T178137#6921107 <https://phabricator.wikimedia.org/T178137#6921107> where our CI will happily let something through to production with bugs in it because of the convoluted CI setup around `mediawiki-vendor`. The fact that this was caught was again chance and luck rather than having a process that avoid this kind of thing. This also relates to T179663 <https://phabricator.wikimedia.org/T179663>, as the situation described above again covers the dependencies of Wikibase being ahead of those in `mediawiki-vendor` for some period of time, and not automatically being flagged up, again leading to broken situations that will happily be deployed. I stand by what I have said multiple times being that the `mediawiki-vendor` workflows and the CI tired to development should be separated to avoid all of this complexity and pain that has become a recurring theme. TASK DETAIL https://phabricator.wikimedia.org/T279898 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore Cc: hashar, Jdforrester-WMF, Tonina_Zhelyazkova_WMDE, Tarrow, Addshore, Aklapper, Invadibot, maantietaja, Mgagat, Akuckartz, Totolinototo3, Redabr4, Zanziii, Sadisticturd, Nandana, A.S.Kochergin, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
