Last modified: 2013-01-18 20:54:45 UTC
I've noticed that there are spurious phpunit failures. A rebase, triggering a retest, tends to workaround the issue. I've given one that there does not seem to be a bug for. I don't know if there are others. On the integration server, one example is https://integration.mediawiki.org/ci/job/mediawiki-core-phpunit-api/1029/console . The relevant excerpt is: 06:27:05 [exec] There was 1 error: 06:27:05 [exec] 06:27:05 [exec] 1) ApiBlockTest::testBlockingActionWithNoToken with data set #1 ('unblock') 06:27:05 [exec] PHP_Invoker_TimeoutException: Execution aborted after 2 seconds The relevant change is https://gerrit.wikimedia.org/r/#/c/41808/ . There is nothing PHP or API-related in the change. It looks like the timeout is relatively short, but when it's exceeded, it fails the test. This is disruptive to people working on unrelated code.
I don't think that it has anything to do with that test in particular. Looking through past tests that failed in mediawiki-core-phpunit-api, it's not always the same one. These are particularly odd: https://integration.mediawiki.org/ci/job/mediawiki-core-phpunit-api/1009/console https://integration.mediawiki.org/ci/job/mediawiki-core-phpunit-api/1008/console The test that failed in those instances does almost nothing, it just asserts that a local variable was set in setUp(). And I note that a number of the mediawiki-core-phpunit-api tests that have failed recently due to timeouts are failing in TestUser::__construct() on line 48. I'm going to change the component on this to "Unit tests" to get input from people more familiar with that area of the code.
(In reply to comment #0) > A rebase, triggering a retest, tends to workaround the issue. Note that you can just comment 'recheck' to do this as well.
I got sick of waiting, so I just made a changeset to mark all API tests as "medium". Gerrit change #44685.
Change-Id: I48630736a3d06574876fd1fa3d90899cfbc48012
