Investigate support for Docker compose

[melix]

Feature description

Docker compose support is available in test containers. Investigate how we could use this.

https://www.testcontainers.org/modules/docker_compose/

[jamesdh]

I tinkered with spring-boot-docker-compose in a Spring Boot 3.1 app this week, and one of the nice things about using it for local development is that it makes it dead simple to define specific/static connection details for your containers, thus it's super easy to configure your IDE/dev tools to connect to Postgres for instance.

With the current implementation of micronaut-test-resources, it seems I'm unable to do that since defining any of the connection details results in the container being skipped on startup. I have to instead modify the connection details on every startup within my dev tools.

[jamesdh]

Related to #185

[melix]

With the current implementation of micronaut-test-resources, it seems I'm unable to do that since defining any of the connection details results in the container being skipped on startup. I have to instead modify the connection details on every startup within my dev tools.

Well yes, that's precisely the point : test resources take care of spawning the containers for you (with test containers doing the hard work), so if you want to specify explicit connections, test resources is not what you should use.

However, I understand that the underlying use case is being to be able to use your IDE to connect to the database while it's running, so you need the connection details. I created this issue which may help. Alternatively you could add a bean which logs the connection details on the console. This is obviously not as practical since the details would change on every run (because the container port changes), but it's what we have for choosing that implementation.

The docker compose test resources could be an alternative, as long as we find a way to declare which properties it can resolve, but it would also require disabling the standard JDBC test resources resolvers (or they would conflict on the same property).

At this stage it's still unclear to me how we can implement that concretely, but I'm commenting so that you have all the context.

[jamesdh]

The control panel really isn't helpful. We can get the same information from the logs on startup. In any case, it's really tedious to have to look that up on every restart of the app.

test resources take care of spawning the containers for you (with test containers doing the hard work), so if you want to specify explicit connections, test resources is not what you should use

I would agree if test-resources was strictly only useable for running tests. But its use has expanded into general development containers and that requires some additional configurability in order to really be useful there. Even the bare minimum, like being able to define the port mapped to the container, would be incredibly helpful.