Either upgrade PHPUnit on Jenkins (T99982) or make it a Composer dependency that can be specified per repo (T90303) or just rewrite AuthManager ( https://gerrit.wikimedia.org/r/#/c/195297/ ) to use crappy old PHPUnit calls.
Description
Status | Subtype | Assigned | Task | |
---|---|---|---|---|
· · · | ||||
Resolved | Anomie | T91699 Create AuthManager framework and core classes | ||
Resolved | Anomie | T110274 Fix PHPUnit version incompatibility between AuthManager and Jenkins | ||
Resolved | Krinkle | T99982 Upgrade PHPUnit to 4.0+ | ||
Resolved | None | T90303 Fetch dependencies using composer instead of cloning mediawiki/vendor for non-wmf branches | ||
· · · |
Event Timeline
For this to work with per repo versions ( T90303 ) core needs to be made compatible with a newer phpunit version. Currently core has in composer.json a require-dev defined on phpunit with version 3.7.37. As an extension like AuthManager needs Mediawiki around, to be able to use a newer phpunit both need to specify a phpunit dependency that has at least one common version.
AuthManager isn't an extension. See https://gerrit.wikimedia.org/r/#/c/195297/
As for core, I can locally run "make safe" with PHPUnit 4.7.6 and have no core tests failing except for a parser test "Magic Word: {{NUMBEROFFILES}}" (for some reason {{NUMBEROFFILES}} returns 2 locally versus 5 expected by the test).
If it were split off as a composer component then you could use the composer-test jobs from the CI to run the phpunit specified in the composer.json file. But as long as it is in core it is as alluded to in T99982#1329560 basically blocked by T105638 which AFAIK is not (yet?) a goal for the WMF.
It wouldn't make sense as a composer component.
As for T105638, I have no idea whether that's a real requirement or an "it would be nice" of some sort, and I don't care to learn enough about composer to figure that out.
I don't think we would ever want to commit require-dev libraries into mediawiki/vendor so T101123: automatically build and commit mediawiki/vendor (composer) is a red herring. I know there was discussion at some point of converting the mediawiki/core Jenkins tests to run via composer test but I don't know if anyone ever worked on doing that much.
No because T101123: automatically build and commit mediawiki/vendor (composer) implies not needing to run CI jobs with vendor.git anymore, because vendor.git always contains what composer install --no-dev will give you. There being no difference means that you don't need CI to test both variants. No CI job using vendor.git means T112895: Support installing composer require-dev packages together with mediawiki/vendor does not need to be solved.
We took the "just rewrite AuthManager to use crappy old PHPUnit calls" option a while back.