Clean way to disable the pcov PHP Extension

[sylfabre]

Description

Use phpdismod to disable th pcov PHP extension

Related issue:

#3470

Check list

• Related issue / work item is attached
• Tests are written (if applicable)
• Documentation is updated (if applicable)
• Changes are tested and related VM images are successfully generated

[miketimofeev]

@shivammathur could you please also take a look at this PR?

[shivammathur]

@sylfabre
Using phpdismod would create a breaking change in shivammathur/setup-php action. That is why I choose to edit the module ini file, which would not.

Anyone using pcov can add extension=pcov.so to a ini file. This is consistent with PHP documentation for loading an extension.

But I understand that phpenmod and phpdismod by ondrej are conventionally used in ubuntu, so if it is too much trouble for Azure users, I'm ok with using phpdismod and will make the necessary changes to setup-php.

So, if using you are using phpdismod, I would recommend adding a line in the docs for ubuntu below PHP version table mentioning that pcov is disabled and can be enabled by using phpenmod.

[sylfabre]

@shivammathur Thank you for your feedback and explanation.

The files in the mods-available folder actually are like templates to be copied/symlinked to [context]/conf.d folder of each possible context (apache2, fpm, cli, ...) for which an extension could be enabled. It works the same way as with Apache if you're familiar with it.

So deleting these files' content from mods-available is a bad practice.

You can also simply delete the pcov.ini file from /etc/php/[version]/cli/conf.d folders if you want to disable it without the use of an external tool like phpenmod/phpdismod (I made the assumption that the only relevant context for PHP in Azure DevOps or Github Action is CLI)

[sylfabre]

@shivammathur And you could also challenge the default choice of xdebug over pcov.

In my opinion, pcov is going to be the new standard for code coverage as it runs faster and consumes less memory that xdebug (https://medium.com/@nicocabot/speed-up-phpunit-code-coverage-analysis-4e35345b3dad).

That's why we are using pcov at my company.

But in the end, this is a product choice that belongs to you guys!

[shivammathur]

@sylfabre
They are few, but I know projects testing with php-fpm and other sapi as well. So the set of extensions should be consistent. That is why I changed the main module ini file instead of symlink in cli. I'm ok with changing it to use phpdismod as that handles all sapi.

Ideally both pcov and Xdebug should be disabled as they add overhead to PHP and can be enabled if needed in the workflow. But changing this either way would be a breaking change.

[sylfabre]

@shivammathur Ok I understand why you changed it that way.

What are the next steps please?

[shivammathur]

Documenting that PCOV extension is disabled, with the steps to enable it using phpenmod would be great. This can be added below the PHP version table similar to how MySQL service is documented.

@miketimofeev What are your thoughts on this.

[sylfabre]

@shivammathur I've updated the doc as per your request

[AlenaSviridenko]

Hi @sylfabre,
we do not mind making code changes, but updating documentation with instructions how to switch different extensions in PHP is a bit out of scope of our README purpose.
Could you please remove documentation updates, then I will run test CI to validate your changes.

[sylfabre]

@AlenaSviridenko I did it as per the request of your colleague #3472 (comment)

Let me know if you want the doc or not

[shivammathur]

@AlenaSviridenko I would suggest keeping the documentation to avoid further issues regarding this.

[AlenaSviridenko]

We'd prefer to avoid adding any tool specific instructions to our readme. I understand that we have some for MySQL for example, but we decided that adding instructions for tools will complexify our documentation.
I think, we can have a part of the note like "Both Xdebug and PCOV extensions are installed, but only Xdebug is enabled." without instruction how to switch them.

[shivammathur]

@AlenaSviridenko Fair enough

[miketimofeev]

@sylfabre could you please pull the latest main to your branch and make a change that @AlenaSviridenko suggested in #3472 (comment)?

[sylfabre]

@miketimofeev Done