Page MenuHomePhabricator

Fix PHPUnit version incompatibility between AuthManager and Jenkins
Closed, ResolvedPublic

Description

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.

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr subscribed.

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.

an extension like AuthManager

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 forgot if we somewhere already thought about how to handle require-dev together with mediawiki-vendor. I created T112895 for this. If we have a solution for that we could switch core to use that maybe without solving T101123, which is why I thought T105638 would be a requirement.

I forgot if we somewhere already thought about how to handle require-dev together with mediawiki-vendor. I created T112895 for this. If we have a solution for that we could switch core to use that maybe without solving T101123, which is why I thought T105638 would be a requirement.

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.

Anomie claimed this task.

We took the "just rewrite AuthManager to use crappy old PHPUnit calls" option a while back.