Add restart option to spring.docker.compose.start.command

[Mumeii]

Problem :

Right now, while using the Spring Boot Docker compose feature during my tests writings, I sometime forcefully stop them, either from command line or Intellij IDE

In such a case :

• this feature don't have the time to apply the stop step asked with spring.docker.compose.lifecycle-management=start_and_stop
• the container stay there, hanging around in a transient state

If I forget to cleanup those remaining containers myself, they'll be reused during my next test campagne startup, which can lead to tests failing, reporting false negative.

Fair enough, I agree that it's because I'm only human, and sometime forget to apply a mocked DB content cleanup step before each of my tests, which is bad (really really bad I mean 😉)

Proposed solution :

I think it would be great to add an extra restart option for spring.docker.compose.start.command property

That way, I'd be certain that my mocked environment has been restarted from scratch, and the DB initialization scripts that are used in the Docker compose file are replayed each time

I'm fine paying this extra restart time if it avoid me thinking one of my colleagues pushed flacky or failing tests on main whereas the trouble is simply what I have described above 🤦

[philwebb]

Another option might be to add an option to spring.docker.compose.lifecycle-management or tweak start-and-stop.

[hojooo]

Hello! I’m interested in working on this issue and would like to propose an implementation aligned with the current design.
I think it would be helpful to clearly distinguish between “how to start” and “what to do when services are already running”:

• Add DockerCompose.restart (and DockerCliCommand.ComposeRestart) as a common building block.
• Keep spring.docker.compose.start.command for the base start strategy (up | start).
• Introduce spring.docker.compose.start.on-running with values like ignore | restart | recreate:
  • ignore: do nothing if services are running (current behavior)
  • restart: run docker compose restart

This keeps existing defaults/backwards compatibility, removes ambiguity around skip behavior, and provides a clear, extensible policy for the “already running” case. I can open a PR if this direction sounds good.

[philwebb]

@hojooo, Thanks for the offer @hojooo. The current issue is marked as pending-design-work so we're not sure which direction we want to go just yet. We probably won't get to discuss this for a little while as we're pretty stacked with 4.0 work.

[hojooo]

@philwebb Thanks for the update! I’ll keep an eye on this issue and I’m still happy to help once the design direction is clearer.