couturejilo.blogg.se - Configure phpstorm debug docker container

CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER FOR MAC
CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER INSTALL
CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER UPDATE
CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER CODE

Then enable listening for Xdebug in Run > Start Listening for PHP Debug Connections. Don't forget to set the mapping (my project folder is copied to /code in the Docker container when the image is built so the mapping goes from the project root to /code). A host is required, and the localhost value fills in the blank even if it's not really relevant. The server name MUST match the serverName value in the docker run command. Set up a new server in Preferences > Languages & Frameworks > PHP > Servers. Next, you need to set up mappings so that the IDE knows what files Xdebug is talking about. Then open Preferences > Languages & Frameworks > PHP > Debug, and set the Xdebug port to the same value as remote_port. Choose the Docker option, and PHPStorm will automatically find the Xdebug image for you. In Preferences > Languages & Frameworks > PHP, add a new CLI Interpreter. I use PHPStorm, but a different IDE will be set up in a very similar way.

CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER CODE

PHP_IDE_CONFIG is used to pair the Xdebug instance and your project code with the IDE. remote_port needs to match your IDE settings. Other versions (older or other OS) will need to get the IP.

CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER FOR MAC

Newer versions of Docker for Mac (17.06 and newer) can conveniently use to connect from the Docker container to the host.

XDEBUG_CONFIG env variable sets the remote_host and remote_port Xdebug properties. env "XDEBUG_CONFIG=remote_host= remote_port=9000" \ Variables like remote_host, remote_port or serverName should not be stored in the repository and are runtime specific. docker/xdebug/debug.ini file, but I'd recommend against it. However, Xdebug needs environment or ini file variables to setup the connection to your host machine for live debugging. docker run -rm myapp-xdebug /code/vendor/bin/phpunit -coverage-clover build/logs/clover.xml It may need a bit of tweaking of the file, but the PHPUnit CLI will tell you what to do. You can now run PHPUnit with the code coverage option. Now you can build the image using docker build -file Dockerfile-xdebug -tag myapp-xdebug.

The the content of the file took me a while to figure out and is a key to running Xdebug in a CLI app properly. docker/xdebug/xdebug.ini is a local relative path, and the file is stored in the repository. docker/xdebug/xdebug.ini /usr/local/etc/php/conf.d/xdebug.ini

CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER INSTALL

RUN pecl install xdebug \Īnd then copy the xdebug.ini setting file. Let's see what commands were added to the original application image.įirst, you need to install and enable Xdebug in the image. I could have used the application image as the source (using FROM), but we tend to keep the image structure as flat as possible, so a plain copy&paste in this case. It is very similar to the original application image. So I have another Docker image and a separate Dockerfile just for Xdebug. Building Xdebug into this image would not be wise, because you don't want to have an image with Xdebug run your production app. This code builds the image with the application, runs the tests on Travis CI, and then (if tests pass) deploys it to AWS ECR. & mv /code/composer.phar /usr/local/bin/composer no-install-recommends & rm -r /var/lib/apt/lists/*

CONFIGURE PHPSTORM DEBUG DOCKER CONTAINER UPDATE

RUN apt-get update & apt-get install -y \ The application is based on a very simple Dockerfile. They simply didn't lead to a working debugger in my setup: I went through a lot of articles touching on the subject, many of them were outdated, focused on web applications or very confusing.

code coverage generated when running PHPUnit tests.

Having Xdebug in your app will give you 2 major benefits: We have a nice boilerplate that helps bootstrapping the repository with all the required tools (from integration with Travis CI to static code analysis), but I was missing one piece that comes in handy when I need to debug - a debugger. The majority of my coding are simple CLI applications. Select your deployment server, and on the Mappings tab, click the Add New Mapping button.Īdd an additional entry that maps the /MyProject/public folder to the server document root /.Īs a result, the URL to access the validation script becomes the correct. In the Settings dialog ( Control+Alt+S), go to Build, Execution, Deployment | Deployment. To solve this, you need to set the explicit mapping between the public subfolder and the server document root. If the entire project root folder is mapped to the server document root, PhpStorm will attempt to access the validation script via the URL, which will result in a 404 error. The server document root is set to its public subfolder, that is /MyProject/public. The project is stored in the /MyProject folder. The issue can happen in situations when the server document root is different from the project root, and deployment path mappings are not configured correspondingly.