|Resolved||hashar||T232706 mwcore-phpunit-coverage-master times out after 5 hours|
|Open||None||T225730 Reduce runtime of MW shared gate Jenkins jobs to 5 min|
|Open||Daimona||T234020 Switch mediawiki code coverage from xdebug to phpdbg or pcov|
|Open||None||T243847 Add pcov PHP extension to wikimedia apt so it can be used in Wikimedia CI|
Sorry for being gnomic! :-)
For sury-php, we just inject the personal nightly PHP packages that sury makes before they get properly packaged for debian, and so can use versions which aren't approved for each Debian release: https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/dockerfiles/sury-php/Dockerfile.template
While that might have been a slowness cause, it's still insufficient. First of all, we're using xdebug 2.7.*, but 2.9.0 claims a 250% speed up compared to 2.7.0. At least, this is something that could be explored. Second, pcov is still way faster than xdebug 2.9.*, based on local tests; see T234020#5826901 for an example. If the improvement is really that big, it would be foolish not to take advantage of a relatively easy change like switching the coverage driver.
IMHO, we cannot decline this task because "xdebug is already faster" without knowing first how much pcov can be faster than xdebug.
phpcov coverage is also slightly different.
It is, but is that a problem? As I wrote in T234020#5826901, the only notable differences are that pcov ignores lines with a global declaration (i.e. global $wgFoo), and the first line of switch expressions (i.e. switch ( $foo )). Is it bad not to have these lines show up as coverable? IMHO, no. Especially if that comes with a noticeable performance improvement.
Memo (for myself or whoever is interested): xdebug 3 should supposedly bring massive performance improvements. Copying from the release notes for 3.0.0beta1:
This made it possible to massively increase performance in many of Xdebug's sub systems as Xdebug is now much more conservative in which hooks are enabled.
Configuration changes, massive performance improvements, and PHP 8 support are the primary features in Xdebug 3
Once a stable is version is released, we should check its performance compared to pcov. If it turns out to be similar or better, we might consider staying with xdebug, as long as we upgrade it to version 3. Note, IMHO it's still subpar to use an "all-in-one" debugger for coverage (because dedicated coverage drivers like pcov or phpdbg should in principle be faster), but I guess upgrading xdebug would be easier, thus acceptable (at least temporarily).