I'm using: - SB 3.1.3 - liquibase 4.20 - testcontainers 1.18.3

I came accross this article: https://www.atomicjar.com/2023/05/spring-boot-3-1-0-testcontainers-for-testing-and-local-development/ and I was very happy with this.

Then I wanted to bump only 1 postgre container for my test suite (instead of multiple). Here is the MR 1 to do it. As I'm using it for both test and local startup this first implementation broke the local startup. I fixed it with this MR 2.

Issues

  1. And now when I'm running my local with ./gradlew bootTestRun I'm having 2 postgre containers running (instead of 1). I find a workaround by commenting this line but it's not what I want
  2. I also wanted to remove those lines (because I'm using the new @ServiceConnection) but I cannot without errors. You can see the github action ouput for more details

Related issues - https://github.com/spring-projects/spring-boot/issues/37276 - https://github.com/spring-projects/spring-boot/issues/36946 - https://github.com/spring-projects/spring-boot/issues/36418

My repository is here

Comment From: wilkinsona

From what I can tell, your use of @ServiceConnection in ContainersConfiguration is incorrect as it's being used in a location where it's unknown to Spring Boot. As shown in AtomicJar's blog post that you've referenced, it's typically used on @Bean methods or on fields in a test class. I suspect that this is why you could not remove the code that sets the spring.datasource.* properties. Looking at MR1, it seems to have moved things in the wrong direction. Unfortunately, I don't understand what you mean by "I wanted to bump only 1 postgre container for my test suite" so I can't suggest an alternative.

Two containers are being started as you have defined one as a @Bean in LocalContainersConfiguration. This container will be started by Spring Boot. The second is being started by your code in ContainersConfiguration. When the class is loaded, postgreSQLContainer is initialized which calls start(). ContainersConfiguration is being loaded as LocalContainersConfiguration references ContainersConfiguration.DOCKER_IMAGE_POSTGRES.

Comment From: fleboulch

Thanks for your reply!
I'm trying to implement a solution for the problems explained in this article.
In my test suite I had 9 postgre containers created (and stopped) before the MR 1. It was slow
With the implementation of the MR 1 I reduce the number of postgre containers to 1 because it's shared in all my test suite. Execution is much faster (time has been divided by 2.5)

I can implement the solution mentionned in the article but I'm using testcontainers for both tests and local development. And I don't know how to use my postgre container for the local development with his solution

Comment From: wilkinsona

Unfortunately, this isn't the right place to get some help with a technique described in a blog post that wasn't published by the Spring Boot team. I can't see any signs of a ContextCustomizerFactory in your repository so it's not clear to me how you have attempted to implement the described approach.

Context customizer factories are only called when running tests so you can't reuse such a factory when running your application's main method for local development. Instead, you'll need a separate entry point that's for local development, possibly calling some common code that's also used by the context customizer factory.

If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: fleboulch

I finally fix the issue using withReuse(true)
Thanks a lot for your help