Page MenuHomePhabricator

composer-package-php72-docker runs with xdebug enabled
Open, Needs TriagePublic

Event Timeline

(FTR, I'm not sure if this is intentional, but I believe it may slow things down. There are several recent changes in integration/config, so one of those is likely the cause)

Hmm. Yes, that line is new as of 1d98a7264, but that was just duplicating the code in the now-removed composer-package-php70 image - see That dates from back when the image was just called composer-package, and was originally added in efed77aedccf57b57005502f307aabe252fc034c in 2017.

Perhaps that line didn't have any effect beforehand, but was meant to have?

Perhaps that line didn't have any effect beforehand, but was meant to have?

It almost certainly didn't have any effect, AFAICT. Trying to run phan with xdebug enabled will print a noticeable warning (like it did in the link above), and I've never seen that on a composer-package-* job. Since nobody complained about it in the past 3 years (apparently), I'm wondering whether it could be disabled again.

An interesting side effect of this: phan restarts itself if xdebug is enabled, but in doing so, it seems to pick PHP 7.3 in the php74 image, see

18:23:26 [debug] Running '/usr/bin/php7.3' '-n' '-c' '/tmp/SJp3ec' './vendor/phan/phan/phan' '--project-root-directory' '.' '--config-file' 'tests/general-phan-config.php' '--output' 'php://stdout' '--long-progress-bar'

Of note, if that change is meant to let composer-package jobs run PHPUnit with support for code coverage, once again I think that should use pcov (T234020) which can be left unconditionally enabled with a very tiny performance overhead (at least based on what I do locally), and that wouldn't cause a restart of phan.

It seems like xdebug was enabled for more jobs. As a case in point, all phan jobs are now running with xdebug enabled, see extension run, core run. Fortunately, it has basically no effect on phan because it restarts itself without xdebug.