Page MenuHomePhabricator

Install extension require-dev dependencies in wmf-quibble-vendor-mysql-hhvm-docker
Open, MediumPublic

Description

Adding a new require-dev dependency to mw extensions passes the initial static analysis checks for this job, the dependencies are correctly installed and checked against. The second half of the job though, running the phpunit tests, uses vendor.git and only adds the require-dev dependencies from mw core and vendor, but not the extensions.

The current workaround is to add extension require-dev to vendor.git, but this doesn't seem very sustainable. quibble should pull in the appropriate require-dev parts from all installed extensions.

This is somewhere around quibble.cmd.QuibbleCmd.fetch_composer_dev

Event Timeline

Indeed extensions development dependencies are not fetched by the composer-merge-plugin and that is unfortunately on purpose :/ The composer.json of each extensions would most definitely have some version mismatches on various dev dependencies and such a merge would never pass.

I remember we had some discussions on that front with the hamcrest library though it benefited any extensions and core. So that ended up in mediawiki/core require-dev. Reference:

require-dev in extensions was at first just for composer install && composer test, there is no way though in composer.json to disambiguate dependencies that should be merged from some that should not. We are really hitting the limit of our systems and need a new definition? Maybe an extra field for the composer-merge-plugin which will let it merge some specific dev dependencies but none of the others.

Maybe Platform Engineering can assist on that front.

kchapman subscribed.

Added TechCom for visibility. This isn't a system Core Platform runs, maybe something for SRE?

pinging @bd808 for input

@hashar is the local expert on the CI integration related to composer usage. He was the awesome human who came up with the initial implementation of mediawiki/vendor.git and how to use it in CI and production to satisfy the security concerns of both environments.

Maybe an extra field for the composer-merge-plugin which will let it merge some specific dev dependencies but none of the others.

This is possible, but probably also fragile. I'm not sure that there is a really good automated solution for what are essentially integration tests across components with uncoordinated "require-dev" dependency declarations. In order to perform the integration, someone must define the runtime of the system in a way that resolves the conflicts that may arise from combining things that were not implemented as a fixed suite. Composer has built-in capabilities for this in its internal DependencyResolver component. That capability has limitations however in that it can only find resolution if all declarations for a given library have some area of intersection. If asked to resolve a conflict between a request for "foo:>1.0,<2.0" and "foo:>=2.0" it will fail and require a human to figure out how to upgrade/downgrade the specifications for foo to allow for a single version satisfying both constraints.

One way to solve this would be just to implement what @EBernhardson has asked for: full use of require-dev across all Composer components involved in the test. @hashar is certainly correct that this will lead to conflicts in certain combinations. These would however become blockers to a clean test and thus things that humans would be able to notice and resolve. We already have semi-automated processes for things like version bump of mediawiki-codesniffer across a large collection of PHP projects. Expanding that to include other common development dependencies such as phpunit seems possible.

Krinkle triaged this task as Medium priority.
Krinkle subscribed.

Re-triaging for TechCom –

This is first and foremost a feature request for the CI configuration of MediaWiki jobs. In my personal capacity I do have some limited and partially dated experience with this infrastructure and could certainly help design and/or validate ideas for improving this (if needed).

Having said that, Bryan has covered most of what I know already. And while I certainly could help personally, at this point it doesn't seems like something in scope for TechCom to need to approve and/or consult with. Keeping it on our radar for now.

In yesterday's TC meeting, the CI Future WG report was mentioned as well. Wondering whether it does/should cover this use case.

@ Release Engineering: If/when TC's input or my own is needed here, let us know :)

An additional complexity to keep in mind will be extensions that depend on other extensions. The initial workaround we deployed for this ran into issues, it worked for CirrusSearch and mw-core, but extensions that depended on CirrusSearch were failing in CI.

Change 513357 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/vendor@master] Add CirrusSearch dev dependency to require-dev

https://gerrit.wikimedia.org/r/513357

Change 513358 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/core@master] Add CirrusSearch dev dependency to require-dev

https://gerrit.wikimedia.org/r/513358

Change 513371 had a related patch set uploaded (by EBernhardson; owner: EBernhardson):
[mediawiki/extensions/CirrusSearch@master] Validate request logging with json schema

https://gerrit.wikimedia.org/r/513371

Change 513358 merged by jenkins-bot:
[mediawiki/core@master] Add CirrusSearch dev dependency to require-dev

https://gerrit.wikimedia.org/r/513358

Change 513357 abandoned by EBernhardson:
Add CirrusSearch dev dependency to require-dev

Reason:
unnecessary.

https://gerrit.wikimedia.org/r/513357

This task should be retitled now that HHVM is gone. Leaving it alone for now since I'm not sure whether or not composer-merge-plugin is providing some of what's requested here.