Devtools integration with boot dash docker is broken

[kdvolder]

Describe the bug

The root of the problem is that boot dash is not able to determine that devtools is a dependency included in the docker image, as a result all the functionality associated with devtools on docker containers is disabled, (E.g. if you start a boot app with devtools on its classpath by drag/drop onto docker target you will see that the context menu on the container will have `Restart devtools client' as disabled. Similarly you will not see a decoration on the image/container that it has devtools. All of this is working just as if there is no devtools present in the image.

The root cause for all of this is here: paketo-buildpacks/java#3 (comment)

[martinlippert]

Instead of trying to figure out whether the docker image (down the road) has actuators as a dependency, we could solve this in a different way. Since we deploy the project from the IDE, the tooling itself can determine whether actuator is on the classpath of the deployed project (instead of looking at the container). This is probably less accurate (since actuators might be on the classpath of the project, but might not end up in the produced container), but that inaccuracy is probably good enough for most of the cases.

A similar mechanism will be needed to decide whether to automatically connect live hovers to the deployed app or not (to avoid the attempt to connect live hovers to an app that doesn't have actuators), so we could solve two problems with the same solution here.

[kdvolder]

I think the suggestion is a reasonable compromise but indeed it is less accurate. The original implementation (which is now broken) used the data on the image/container as the source of truth because it is in fact the real thing you want to know.

Anyhow... it seems to be the best option. I'll start working on this tomorrow.

[kdvolder]

I think I was able to implement something 'almost' as good as what we had before but without relying on docker image metadata.

The 'trick' is that we 'record' information about whether an image was built to include devtools at 'build time'. I.e. when we call the build command we actually know that

• there is a devtools in the project deps
• we are adding some 'special' argument to build command to not remove it (because by default spring-boot image builder will in fact remove them otherwise)

This 'recorded' info of 'hasDevtools' is stored in a persisted boolean property associated with the image uuid. So we can then use this stored information to replicate the exact same logic we had before.

I also note that there was in fact a test case in our test suite that 'witnessed' the problem.

But I guess we are not running the tests anymore? Or maybe we just stopped paying attention to them?