WIP chore(travis): use phpdbg instead of xdebug for code coverage

[jeabakker]

No description provided.

[hypeJunction]

Try this: phpdbg -qrr -S cli ./vendor/phpunit/phpunit/phpunit --bootstrap ./engine/tests/phpunit/bootstrap.php -c ./phpunit.xml --coverage-clover clover

[hypeJunction]

You need to set the sapi to cli to stop all the logging.
I have tried this locally and a bunch of tests that were dealing with files have failed, therie is next to none info on phpdbg anywhere.

[jeabakker]

but if i set the sapi to cli i get an error from PHPUnit that no coverage driver could be detected :(

see https://travis-ci.org/Elgg/Elgg/jobs/318515710#L833

[jeabakker]

Here https://github.com/sebastianbergmann/environment/blob/master/src/Runtime.php#L171 you can see how PHPdbg is detected, which is based on SAPI name

[hypeJunction]

Then just add phpdbg to Printer service constructor

[jeabakker]

you mean here https://github.com/Elgg/Elgg/blob/master/engine/classes/Elgg/Di/ServiceProvider.php#L387

add a new, or direct it to cli?

[hypeJunction]

In_array should do I think

[jeabakker]

i think it's using phpdbg correctly now, but still run into a resource problem in the plugins testsuite

https://travis-ci.org/Elgg/Elgg/jobs/318679268#L964

The command "phpdbg -qrr ./vendor/phpunit/phpunit/phpunit --configuration ./phpunit.xml --testsuite plugins --coverage-clover plugins.clover" exited with 137.

which indicates out of memory
https://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error

and some other strange build errors on stuff i didn't touch.......

[jeabakker]

@Elgg/core anyone an idea why this https://travis-ci.org/Elgg/Elgg/jobs/319055552#L900 would fail only in the code coverage test?

And an idea how why can make the plugin tests use less resources, as mentioned above?

[hypeJunction]

Some forums suggesting:

sudo: required
dist: trusty

[jeabakker]

Is already the case Op 20 dec. 2017 12:58 p.m. schreef "Ismayil Khayredinov" < notifications@github.com>:

…

Some forums suggesting: yml sudo: false dist: trusty — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA11Jn94fxWyohDwbHK49LKCC5ZCHJbTks5tCPZegaJpZM4Q_AKN> .

[hypeJunction]

https://github.com/jeabakker/Elgg/blob/76cf05c2787cf2aeeac0ac06079dce2663192f20/.travis.yml#L9
https://travis-ci.org/Elgg/Elgg/jobs/319055552/config

[jeabakker]

a comparison of the available build environments https://docs.travis-ci.com/user/reference/overview/#Virtualization-environments

sudo: required
dist: trusty

would give more memory, but takes longer to start

[hypeJunction]

I imagine this can be done just for one of the builds

[jeabakker]

new errors :( 'too many open files'
https://travis-ci.org/Elgg/Elgg/jobs/319691233#L972

I tried upping the limit with ulimit -n unlimited which isn't allowed https://travis-ci.org/Elgg/Elgg/jobs/319631519#L836

even with sudo
https://travis-ci.org/Elgg/Elgg/jobs/319637719#L845

[hypeJunction]

Can we just go back to scrutnizer grinding the code coverage until you figure out how you want Travis to handle the queue without making everyone wait for 3 hours?

[jdalsem]

the alternative is timeout and waiting for scrutinizer... in both services we need to solve wait time issues

[jeabakker]

Can we just go back to scrutnizer grinding the code coverage

for now restored scrutinizer config

[hypeJunction]

I don't care so much about scrutinizer, we don't have to wait for it to merge things. It's like a dessert that's nice to have.

[hypeJunction]

Travis code coverage job needs to go away for now. Restoring scrutinizer config doesn't fix the problem of halted builds on Travis. We only have 5 containers, and until those jobs complete no new containers are available.

[jeabakker]

will try this again at a later date