ddev-intellij-plugin
ddev-intellij-plugin copied to clipboard
php-perfect
Stop setting COMPOSE_PROJECT_NAME
Is there an existing issue for this?
- [X] I have searched the existing issues
Are you sure that this bug is related to this DDEV Integration Plugin?
- [X] I am sure
Enter your error report ID (If available)
No response
Describe the bug
COMPOSE_PROJECT_NAME is not required to be set in DDEV v1.21.1+, so
- Stop setting it
- Make dependency on DDEV v1.21.1+
Note that there would have been a problem with the current approach because the name wasn't sanitized to remove periods, which is important for docker-compose.
Steps to reproduce
No response
Additional context
No response
Scheduled as an optimization for v1.1 as setting it has no negative impact, so it's not urgent.
FYI, I keep getting "failed to start docker-compse service" for example when trying to configure PHPUnit in PHPStorm.
I think behind it is the issue described here: https://youtrack.jetbrains.com/issue/WI-63293/Problems-with-COMPOSEPROJECTNAME-when-actual-project-name-contains-a-dot
Therefore, not setting the COMPOSER_PROJECT_NAME will probably help me and other people with this issue.
That's interesting; DDEV has removed dots from COMPOSE_PROJECT_NAME because of this bug for a year or more.
You are right!
After some debugging, I just found out that the dots weren't actually the issue, as these are nowadays removed by ddev when the docker-compose project name is assembled.
For some reason though, the envionment variable "COMPOSE_PROJECT_NAME" still needs to be set in order to make the DDEV CLI Interpreter work with the necessary "connect to existing container" lifecycle mode. I'm working with ddev v1.21.5-alpha1 and Docker 23.0.1.
In my project specifically, the actual problem was that the environment variable contained the wrong value for some reason. Maybe because I had an old version of PHPstorm with plugin version 1.0.3. I manually changed the environment variable value to the name listed by ~/.ddev/bin/docker-compose ls which solved the problem for me, as I am unable to reproduce it with a fresh project and the 1.0.4 version of the plugin.
PhpStorm is using docker-compose directly, not running ddev to do the things it wants.
Do I understand that all your issues are solved? If so, please close this, thanks!
Yes, personally my issue is solved for now. However, I'm not entirely sure if things will still work if this issue here is put into action and the plugin wouldn't set the COMPOSER_PROJECT_NAME in phpstorm anymore. What I can say is that in my setup, when I delete the envionment variable manually, phpstorm is unable to connect to the docker-compose service.
What I can say is that in my setup, when I delete the envionment variable manually, phpstorm is unable to connect to the docker-compose service.
I can confirm that. Thanks @moe2k!
I will close this issue as removing the environment variable will break the integration.
I don't believe this should be the case. I just tested, and I'm certainly able to run ~/.ddev/bin/docker-compose -f .ddev/.ddev-docker-compose-full.yaml up without COMPOSE_PROJECT_NAME being set.
In https://github.com/ddev/ddev/pull/4124, the name attribute was added to the .ddev/.ddev-docker-compose-full.yaml, explicitly to make it so this wasn't needed. It was merged Aug 17, 2022.
It's not clear that anything was done in the plugin here about this @nico-loeber - Is the plugin setting COMPOSE_PROJECT_NAME?
Removing the COMPOSE_PROJECT_NAME environment variable still results in the following error, @rfay:
Testet with ddev 1.22.5 and the main branch of the plugin.
Let's reopen this and see if we can sort it out. People with dots in project name still get trouble. Are you removing dots from COMPOSE_PROJECT_NAME? (They're not allowed by docker-compose)
Please use current DDEV version in your testing. I don't expect that would have anything to do with this problem though. Current DDEV is v1.22.6
From what I can tell, the IDE is doing something weird. When setting the service without COMPOSE_PROJECT_NAME, the progress bar that pops up for a moment shows that it's trying to run docker compose up -d, which isn't the expected command:
Maybe it's not detecting that the docker compose project is already running and tries to start it up before running exec.
When changing the configuration from exec to run, the php check passes, although that's not the configuration you'd want to use with DDEV.
Thanks for chasing this. There is really no place that we want PhpStorm to do a docker-compose up, in (I think) every situation it should be doing docker-compose exec
Enabling logs for com.jetbrains.php and com.intellij.docker, the theory seems to be confirmed. Without COMPOSE_PROJECT_NAME, this appears in the logs:
2024-08-23 16:04:22,659 [2142620] FINER - #c.i.d.r.DockerComposeContainerUtil - Failed to find container with 'ddev' or 'ddev' project name
2024-08-23 16:04:22,661 [2142622] INFO - #c.i.d.r.DockerComposeServiceStarter - Starting docker-compose: /usr/bin/docker compose -f /home/akiba/Projects/uptime-monitor/.ddev/.ddev-docker-compose-full.yaml up -d web
When setting COMPOSE_PROJECT_NAME, this happens instead:
2024-08-23 16:14:41,864 [2761825] FINER - #c.i.d.r.DockerComposeContainerUtil - Container with name '/ddev-uptime-monitor-web' was successfully found
It seems to be running a docker ps to get a list of running containers, and then look for one that matches <project_name>-<service_name>. If it doesn't find one, it automatically does an up -d:
Snippet from com.jetbrains.php.remote.docker.compose.PhpDockerComposeRemoteProcessRunner::getProcessOutput
Super interesting
The .ddev/.ddev-docker-compose-full.yaml has name in it, which should override anything else. But I guess PhpStorm doesn't know that.
name: ddev-d10
I guess PhpStorm isn't looking correctly if the variable isn't set, so it doesn't find the container, so it tries to start up the compose stack itself.
Ah, it's using COMPOSE_PROJECT_NAME to determine the project name, rather than execute the .ddev-docker-compose-full.yaml
It's assuming that COMPOSE_PROJECT_NAME is there for it instead of for docker-compose.
I was scratching my head a bit where the ddev as project name that it's trying is coming from. After experimentation, I can confirm it's the cleaned up directory name the yml is in. When I copy the ddev yml into a directory called .testdev, then the IDE complains about not finding a testdev container.
Very interesting finding @AkibaAT!
But could someone explain again why setting the environment variable is a problem? I didn't notice any issues...
It's not a problem actually. It's just that although DDEV once used it when starting docker-compose up, that was years ago, and it was replaced with name in the .ddev-docker-compose-full.yaml.
The reason this came up (IIRC) is that somebody was trying to set up PhpStorm manually and they stumbled on this (it's documented in https://ddev.readthedocs.io/en/stable/users/install/phpstorm/#manual-setup)
But ... if it weren't for PhpStorm using it inappropriately for its own purposes, we wouldn't care to ever set it.
But I'll close the issue rather than fight this in the PhpStorm issue queue.
Thanks for studying it so successfully @AkibaAT !