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 created this task.Aug 26 2015, 4:57 AM
Tgr updated the task description. (Show Details)
Tgr raised the priority of this task from to Needs Triage.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 26 2015, 4:57 AM
Anomie added a subscriber: Anomie.Sep 16 2015, 5:36 PM

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.

Anomie added a comment.EditedSep 17 2015, 1:42 PM

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.

JanZerebecki updated the task description. (Show Details)Sep 17 2015, 2:34 PM
JanZerebecki set Security to None.

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.

bd808 added a subscriber: bd808.Oct 7 2015, 7:37 PM

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 closed this task as Resolved.Dec 10 2015, 4:16 PM
Anomie claimed this task.

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

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 10 2015, 4:16 PM