For a while we've been using DDEV to standardize our docker setup for development and to have a consistent way of interacting with Docker across all our projects (e.g., Magento, Symfony, Sulu, Sylius, API Platform, ...). Since most of our developers are using PHPStorm as their IDE of choice, using the DDEV Tool Integration for IntelliJ IDEA plugin was a natural choice.
Recently, we ran into a problem with PHPStorm and the DDEV plugin. While things were working fine on some of our projects, we had an issue with a project we set up recently. It was impossible to execute PHPUnit via the default DDEV resources (e.g., CLI Interpreter) created by the plugin. When trying to run PHPUnit, the following error appeared in the PHPStorm console:
exec: "docker.exe": executable file not found in %PATH%
Current PATH :
Funny enough, the problem was reproducible on multiple developer machines. We tried to reconfigure PHPStorm, tested several configurations, and adjusted our Docker setup because the error looked like a problem with Docker, but nothing worked.
For some odd reason, the CLI interpreter configured by default via the DDEV plugin could not properly detect the PHP version in the container due to a "Failed to parse validation script output" error. The PHPStorm Debug Logs did not help much to identify the problem.
So I decided to compare a working project's
.idea directories with the project where we could not get it to run. The only difference I found was a missing
PhpInterpretersPhpInfoCache component in the
<phpinfo binary_type="PHP" php_cli="/usr/bin/php8.2" path_separator=":" version="8.2.3">
<!-- ... -->
I tried to copy that part to the project that was not working. The error regarding the undetectable PHP version in the CLI Interpreters section was gone. Trying to run PHPUnit resulted in the same error again. Back to square one.
Since I was running out of ideas, I decided to create a new CLI Interpreters entry myself and copy all the data from the entry created by DDEV. Once I was done, I configured PHPUnit to use the newly created CLI Interpreter. And guess what? This time it worked. I informed my colleague, and the "fix" also worked on this machine. Problem solved.
UPDATE: The problem is fixed with version 1.1.1 of the plugin.