CLI, XDebug, Docker, and VSCode

[maxxd]

Hi y'all.

I've been scrubbing Google for this and from everything I'm reading and seeing, this should be working - problem is it's not... Here's the deal. I've got a docker image spun up with my development environment and all that's fine. I've updated the php.ini on the image with the following:

[xdebug]
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_log="/var/log/xdebug.log"
xdebug.remote_host=host.docker.internal
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_connect_back=0
xdebug.collect_vars=1
xdebug.collect_returns=1
xdebug.collect_assignments=1
xdebug.profiler_enable=1
xdebug.idekey=VSCODE

I created a new config in launch.json as so:

{
  "name": "Remote XDebug",
  "type": "php",
  "request": "launch",
  "port": 9900,
  "pathMappings": {
    "/var/www/html" : "${workspaceRoot}/myDir"
  },
  "cwd": "${workspaceRoot}/myDir"
}

I set a few breakpoints in VSCode in my file on the host system, start the debugger, and docker-compose run into the image, where I `php test.php` and expect to be brought into the debug session as I would on the host system (that part works). However, it doesn't happen - I never get into the debug session on the host system. My xdebug.log does, however, look like everything should be working:

[11] Log opened at 2020-05-04 20:37:03
[11] I: Connecting to configured address/port: host.docker.internal:9000.
[11] I: Connected to client. :-)
[11] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/testing/test.php" language="PHP" xdebug:language_version="7.1.33" protocol_version="1.0" appid="11" idekey="VSCODE"><engine version="2.9.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2020 by Derick Rethans]]></copyright></init>
[11] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
[11] Log closed at 2020-05-04 20:37:03

Oh, and my docker-compose file maps port 9900 on the host to 9000 image.

service:
  build:
  context: '.'
  volumes:
    - ../myDir/:/var/www/html/
    - ../logs/:/var/log/
  ports:
    - 80:80
    - 443:443
    - 9900:9000
  networks:
    - test
  environment:
    - ENVIRONMENT=development
  depends_on:
    - database

Anybody have any ideas? I'm just burning time on this now, but I'd very much like to be able to debug in the docker container because I'm currently working with a couple different companies that use wildly different php/server setups and I don't want to have to try and keep that straight or have to continually nuke my machine.

Thanks in advance!

Edited May 4, 2020 by maxxd

[gizmola]

What OS is your workstation?

[maxxd]

It's a macbook pro - I do try to keep up to date with OSx, though honestly I have no idea what animal, mountain, or lake they're on right now...

Edited May 4, 2020 by maxxd

[gizmola]

24 minutes ago, maxxd said:

It's a macbook pro - I do try to keep up to date with OSx, though honestly I have no idea what animal, mountain, or lake they're on right now...

I am not great at that either.  I have 2 2015 Macbook Pros I use, both on Mojave, but I have decided not to try and upgrade them to Catalina, as I read that it broke a bunch of 16bit apps, and I don't want to spend time or money trying to upgrade things that currently work fine for me.

The main thing I am wondering about is that you are starting up a cli app, and there are some other vsc settings that might be relevant to the cli like:

program: Path to the script that should be launched
args: Arguments passed to the script
cwd: The current working directory to use when launching the script
runtimeExecutable: Path to the PHP binary used for launching the script. By default the one on the PATH.
runtimeArgs: Additional arguments to pass to the PHP binary
externalConsole: Launches the script in an external console window instead of the debug console (default: false)
env: Environment variables to pass to the script

 

[maxxd]

I've seen some articles where they pass `idekey` and `remote_host` via the arguments parameter, but that doesn't seem to make a difference here. I also tried passing the path to the specific script that I'm trying to test - again, AFAIR that didn't make a difference. `cwd` is actually set in my launch file, and again I don't recall `externalConsole` having any affect. The others I didn't know about - thanks for the pointers, I'll do some digging.

The thing I find most annoying is that every tutorial or set up or walk-through I find seems to use a different subset of the launch settings - the only consistent one I've found is `remote_connect_back` should be set to 0 or it won't work. Admittedly, it's probably a setting somewhere else in the system; I'm afraid I may just have to nuke it from space and start over.

[maxxd]

21 minutes ago, gizmola said:

have decided not to try and upgrade them to Catalina, as I read that it broke a bunch of 16bit apps, and I don't want to spend time or money trying to upgrade things that currently work fine for me

I remember we had issues with the Mojave > Catalina upgrade on our iMacs at my last job.

[gizmola]

9 minutes ago, maxxd said:

I've seen some articles where they pass `idekey` and `remote_host` via the arguments parameter, but that doesn't seem to make a difference here. I also tried passing the path to the specific script that I'm trying to test - again, AFAIR that didn't make a difference. `cwd` is actually set in my launch file, and again I don't recall `externalConsole` having any affect. The others I didn't know about - thanks for the pointers, I'll do some digging.

The thing I find most annoying is that every tutorial or set up or walk-through I find seems to use a different subset of the launch settings - the only consistent one I've found is `remote_connect_back` should be set to 0 or it won't work. Admittedly, it's probably a setting somewhere else in the system; I'm afraid I may just have to nuke it from space and start over.

It seems from your logs you are close though.