Results for MDL-44510

• Remote repository: https://github.com/skodak/moodle.git

• Remote branch w11_MDL-44510_m27_phpunit4 to be integrated into upstream master
  • Executed job http://integration.moodle.org/job/Precheck%20remote%20branch/1970

Adding few devs involved in tests, any objection to final dropping of PEAR PHPUnit support which is necessary for future compatibility with PHPUnit 4.x?

0 objections from me about removing the PEAR option to install it

CI servers still use PEAR installations. Me too

The main problem using the composer-only (aka vendor) is that CIs clean the git repos for every run and moving to composer would add some minutes to get the whole vendor stuff installed on every commit.

Why do we need to drop support for PEAR?

PHPUnit 4.x has different layout, the manual loading I did for PEAR before was a nasty hack, it is very fragile.

Why no just symlink your vendor directory on CI server? Anyway I do not think that copying a few phpunit files from some other directory is taking minutes. (Note: you can remove the behat stuff). Anyway once we switch to 4.x all older stables will have to be still using 3.x and your CI will not be able to use PEAR anyway.

If you think that legacy PEAR is awesome feel free to add new bloody hacks to our PHPUnit integration for 3.x/4.x and maintain it forever, if you do not want to do it yourself find some way to fix your CI instead and let my patch to be integrated.

Do you need to be so rude? You asked, I replied saying that PEAR installers are being used.

In the mean time, while moving the integration.moodle.org server to another machine... I'm experimenting about to have linked "vendor" directories.. will tell soon how they behave.

Ciao

For reference: I've created MDLSITE-2885 about to perform the move to composer whenever possible. Just hacking a trying it now...

FYI: I've already moved the 3 CIs (laptop, public-old, public-new) to run composer based phpunit, so that (MDLSITE-2885) is not blocking this anymore.

I did not intend to be rude, sorry if you felt that way.

looks like there are no objections any more, submitting for integration because it was more than 7 days since the original peer-review request. thanks everybody

Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!

Petr, would you mind adding the drop of pear/phar phpunit support into upgrade.txt and perhaps also in some phpunit/release docs? It think this change can hit people out there and better have it officially documented.

TIA! (holding this for some hours).

hello, the phpunit init tells you that you need to use composer: $text = "Can not find PHPUnit library, to install use: php composer.phar install --dev";
I have removed the PEAR PHPUnit install instructions from docs long time ago, there should not be any PEAR info anywhere.

I have added extra commit with upgrade.txt info.

Integrated (master), thanks!

I've done a quick run of all the options with 4.0 installed via composer and worked perfectly.

I was just checking this out, I got phpunit installed and running via both "php admin/tool/phpunit/cli/util.php --run" and "vendor/bin/phpunit".
However when I tryed to run "vendor/bin/phpunit cache/tests/cache_test.php" I got the following:

Moodle 2.7dev (Build: 20140320), pgsql, eb4606aeb06c40ddbdf200fa516d923d9540fb96
PHP Fatal error: Class 'PHPUnit_Util_Class' not found in /var/www/integration/lib/phpunit/classes/autoloader.php on line 167
PHP Stack trace:
PHP 1.

Unknown macro: {main}

() /var/www/integration/vendor/phpunit/phpunit/phpunit:0
PHP 2. PHPUnit_TextUI_Command::main() /var/www/integration/vendor/phpunit/phpunit/phpunit:55
PHP 3. PHPUnit_TextUI_Command->run() /var/www/integration/vendor/phpunit/phpunit/src/TextUI/Command.php:132
PHP 4. PHPUnit_Runner_BaseTestRunner->getTest() /var/www/integration/vendor/phpunit/phpunit/src/TextUI/Command.php:153
PHP 5. PHPUnit_Runner_BaseTestRunner->loadSuiteClass() /var/www/integration/vendor/phpunit/phpunit/src/Runner/BaseTestRunner.php:105
PHP 6. phpunit_autoloader->load() /var/www/integration/vendor/phpunit/phpunit/src/Runner/BaseTestRunner.php:164
PHP 7. phpunit_autoloader->guess_class_from_path() /var/www/integration/lib/phpunit/classes/autoloader.php:55

Fatal error: Class 'PHPUnit_Util_Class' not found in /var/www/integration/lib/phpunit/classes/autoloader.php on line 167

Call Stack:
0.0001 232328 1.

() /var/www/integration/vendor/phpunit/phpunit/phpunit:0
0.0031 581568 2. PHPUnit_TextUI_Command::main() /var/www/integration/vendor/phpunit/phpunit/phpunit:55
0.0031 582184 3. PHPUnit_TextUI_Command->run() /var/www/integration/vendor/phpunit/phpunit/src/TextUI/Command.php:132
2.5600 53512664 4. PHPUnit_Runner_BaseTestRunner->getTest() /var/www/integration/vendor/phpunit/phpunit/src/TextUI/Command.php:153
2.5601 53512736 5. PHPUnit_Runner_BaseTestRunner->loadSuiteClass() /var/www/integration/vendor/phpunit/phpunit/src/Runner/BaseTestRunner.php:105
2.5601 53513328 6. phpunit_autoloader->load() /var/www/integration/vendor/phpunit/phpunit/src/Runner/BaseTestRunner.php:164
2.5601 53513544 7. phpunit_autoloader->guess_class_from_path() /var/www/integration/lib/phpunit/classes/autoloader.php:55

I tested with other tests (eg lib/tests/accesslib_test.php) and encountered the same.

oh, the right way to execute testcase is to use class name, not path - if you specify path only there is some nasty guessing which apparently I did not test, I am going to try/fix it asap

this should fix it 08ec831ff8a6bfaf91fe87b369a8fb0bb6d357da, please pull the extra commit from my branch - thanks a lot for the problem report

Thanks Petr - that fix has been integrated now (tested it on the way and appears to work perfectly) - all yours Simey for proper testing!

Works perfectly here after the change to PHPUnit 4.

Clothes and manners do
not make the man; but,
when he is made, they
greatly improve his appearance.

---- Henry Ward Beecher

What a week, your changes are now part of Moodle, well done!

Closing, thanks!

RIP - https://github.com/sebastianbergmann/phpunit/issues/1229

Yay! (just in time, eh)