Closed localheinz closed 7 years ago
We want to remove xDebug as early as possible. But it seems a composer self-update takes place with a version of PHP that already has xDebug enabled. Can we control that aspect? This is before the before_install
phase.
Once composer has installed what is needed, when we run the tests, we want to generate code coverage.
Can't get Scrutinizer accessing this repo as only the admin can do so.
This is what I have in another project.
script:
- phpunit --coverage-text --coverage-clover=coverage.clover
- wget https://scrutinizer-ci.com/ocular.phar
- php ocular.phar code-coverage:upload --format=php-clover coverage.clover
So, using something like that as a basis and enable/disable xdebug around phpunit should be enough.
@rquadling
We want to remove xDebug as early as possible. But it seems a composer self-update takes place with a version of PHP that already has xDebug enabled. Can we control that aspect? This is before the
before_install
phase.
Noticed this myself, it's especially weird as it doesn't fully update composer itself.
About enabling and disabling, here's what I do: https://github.com/travis-ci/travis-ci/issues/5780#issuecomment-265674505.
Didn't see the composer fix for xDebug. That's going to be VERY useful.
I also like the approach you have. Enable xDebug only when needed.
Happy to go with what you think is best.
Waiting on @beberlei to approve Scrutinizer for this project. Also suggested transferring ownership if he doesn't want to bother with the admin.
This PR
xdebug
in thebefore_install
step💁♂️ This should speed up things, I believe!
For reference, see https://docs.travis-ci.com/user/customizing-the-build#The-Build-Lifecycle.
Also see https://travis-ci.org/beberlei/assert/jobs/182005392#L173: