wodby / php

Generic PHP docker container images
MIT License
155 stars 103 forks source link

XDebug remains always enabled #58

Closed subhojit777 closed 5 years ago

subhojit777 commented 5 years ago

I am using the tag wodby/drupal-php:7.1-dev-4.2.2. A portion of docker-compose.yml looks like:

  php:
    image: wodby/drupal-php:$PHP_TAG
    container_name: "${PROJECT_NAME}_php"
    environment:
      PHP_SENDMAIL_PATH: /usr/sbin/sendmail -t -i -S mailhog:1025
      DB_HOST: $DB_HOST
      DB_USER: $DB_USER
      DB_PASSWORD: $DB_PASSWORD
      DB_NAME: $DB_NAME
      DB_DRIVER: $DB_DRIVER
      PHP_XDEBUG: $PHP_XDEBUG_ENABLED
    volumes:
      - ./:/var/www/html

PHP_XDEBUG_ENABLED is set to 0. However, the container is started with xdebug enabled.

I am using this stack inside our CI. We need xdebug disabled when Drupal is installed, but need it enabled while running the tests, for code coverage. Therefore, we are controlling it using a PHP_XDEBUG_ENABLED shell variable.

What would be the best way to handle this situation?

subhojit777 commented 5 years ago

I managed to do this by not setting PHP_XDEBUG_ENABLED during site install. It creates the container without xdebug. Before test, I set the PHP_XDEBUG_ENABLED variable, and it creates the container with xdebug.

Got hint from {{ if getenv "PHP_XDEBUG" }} https://github.com/wodby/php/blob/master/7/templates/docker-php-ext-xdebug.ini.tmpl#L1

weitzman commented 4 years ago

Its super unintuitive that PHP_XDEBUG=0 has no effect. You have to not set that var at all. Got bitten by this today.

mxr576 commented 2 years ago

I can just second what @weitzman said. Supporting PHP_XEBUG=0 would be easy, isn't it? (cc @csandanov )

csandanov commented 2 years ago

$PHP_XDEBUG is just a simple helper env var to completely disable xdebug ($XDEBUG_MODE=off is close to zero performance impact but not zero) without using $PHP_EXTENSIONS_DISABLE

If it was called $PHP_XDEBUG_ENABLED (note there's no such env var at all since the major upgrade of xdebug extension) I would agree that the value 0 should be supported but since it's not I don't think any changes are necessary.

mxr576 commented 2 years ago

($XDEBUG_MODE=off is close to zero performance impact but not zero)

that should be true, although when I executed PHPBench in the PHP container it kept reporting that xDebug is enabled and I wanted to be entirely sure that xDebug has 0 impact on my benchmarks.

Maybe PHP_XEBUG variable needs a better documentation?

csandanov commented 2 years ago

now documented https://github.com/wodby/php#xdebug

wimleers commented 11 months ago

This is biting me right now, as this would be the work-around I'd like to do in #188.

https://github.com/wodby/php#xdebug says

By default, xdebug extension not loaded to avoid any performance impact.

But that's not what I'm seeing, at least not on wodby/php:8.1-dev. (I use the -dev container to be able to use sudo, to install additional packages.)

weitzman commented 7 months ago

I'm also seeing the Xdebug extension enabled by default and mode=devel by default in Drush's CI. This build uses wodby/php:latest. The only relevant env variable is WODBY_TAG. Is that enough to enable XDebug?

I finally worked around this by setting xdebug.mode=off in a php.ini. A bonus is that our builds are now much faster.