Is there a way to remote debug a test case or application that must be executed within an already running docker container?
I have a docker compose setup that starts multiple containers:
- a running database
- a container that contains the the runtime and build environment for the java application that is developed with IntelliJ
The java application is not startet, the build system is Gradle. The application can be build and tested running gradlew (the Gradle wrapper) within that running container (it has certain settings which respect to users, permissions and python path).
IntelliJ is running on the machine where Docker (for Mac) is then running the docker compose setup. The source code is mounted into the docker container such that the same files are available for IntelliJ and the Gradle build within the container.
Currently if I just want to debug a single test case I need to create a Gradle task, define the agent lib properties to wait for a remote debugger, then execute this task within the container, switch back to IntelliJ and start a remote debugging session.
This is much more complicated than just click on the debug arrow of the single test case within the source code editor. Is there any way to make this more convenient?
请先登录再写评论。
Hi Olav,
Let me look into this and get back to you.
Olav Rabe
Single-click-to-debug should be possible if you use a Docker Compose run target in your usual Application or Gradle run/debug configuration.
We do not have a step-by-step guide for the process in our documentation yet, so feel free to leave additional comments in this thread if you run into any problems.
That's not really working as needed. I guess what I'm looking for is something that is discussed here:
https://youtrack.jetbrains.com/issue/IDEA-202267/Support-development-in-Docker-as-in-VM
And by the way: We have a working solution with VS Code in place. But I won't drop the better refactoring capabilities that IntelliJ provides by switching to VS Code.
This post is a bit older, but are there any updates on this?
My team recently switched to devcontainers, executing the project on the container and remote debugging works fine.
Also building and running tests on a docker compose run target works (somewhat*) as expected.
However, when trying single click debug on our junit test target, the debugger shows `Listening for transport dt_socket at address: 12345` and then hangs indefinately while “instantiating tests” on a Background Task “searching for Tests”, despite the tests being found and executed just fine for a normal run.
Are there maybe any configurations we are not aware of? So far every advice we found was about remote debugging in general, not debugging tests.
* instead of using the running and specified target service, a new container gets created using the same image as the specified service. Also, empty directories with a random uuid for a name get created every single time, which accumulate over time and is a bit of an annoyance.
Hello, Christopher Wolff. Could you please collect (
Help | Collect Logs and Diagnostic Data) and share the IDE logs? I want to check if any related errors are reported there. To share the logs archive, I recommend you to use the JetBrains Uploads service and write here the ID you receive.Hello, Olga Mulina , thanks for the quick reply!
I collected the log data and did upload it as suggested.
The upload ID is: 2024_05_13_2AWVwJStzwMrk5qaFqEfgu
In case it helps you potentially locating the issue, I ran the tests normally and then in debug again, so data following the timestamp 2024-05-13 07:30:00 should contain all the directly related information.
Hello Christopher,
Is it possible to check the issue with some new sample project? Also please try to fully rebuild your existing project (there are some build related errors in log).
By the way, do you use any antivirus software or firewall?
Hello @... ,
thanks for the suggestions, checking with a new sample project indeed helped us to find the error by pure chance, due to setting up the Run Target with Java language runtime and adding Maven, instead with Maven language runtime and adding Java which we did in the actual Project.
This led to the JDK version being automatically configured for the sample project, while we did not explicitly configure it in the added Java language runtime for the real project. Any regular execution of the application as well as normal testing worked as expected, only one click debug seems to really require the JDK version to be set.
After noticing this difference and the one click debug working in the sample project, we just did explicitly set the JDK version for the Run Target of our real project and one click debug immediately worked as well.
Thank you for your support!
Christopher,
Nice to hear that it works fine! Feel free to contact us if you need any assistance.