[Backport stable/8.0] Testcontainer engine lifecycle #313
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
By not immediately starting the engine upon starting the container we become more flexible with the lifecycle of the engine in our extensions. This allows us to start it when we want to, instead of being tied to the testcontainer which has a different lifecycle from the engine. (cherry picked from commit 8ea4c0d)
By default a testcontainer uses the HostPortWaitStrategy. This will wait until all the configured exposed ports have something running on them. Since we no longer start the engine upon testcontainer start, there will by no process running that's using the gateway port. This results in the testcontainer waiting until timeout. By changing the waiting strategy to a LogMessageWaitStrategy we can tell the testcontainer startup has finished by logging a line, without the need of starting the engine already. (cherry picked from commit 66d0381)
The start of the engine was tied to the start of testcontainer. This resulted in the following lifecycle: 1. BeforeAll - start the testcontainer and the engine 2. BeforeEach - stop the engine, recreate it and start it (reset) This causes some strange behaviour. Upon test start we are starting the engine and resetting it without using it. With this change the lifecycle becomes somewhat more natural: 1. BeforeAll - start the testcontainer 2. BeforeEach - start the engine 3. AfterEach - stop the engine and recreate it (new reset) This new lifecycle also matches more closely with the embedded lifecycle where we do: 1. BeforeEach - create and start the engine 2. AfterEach - stop the engine (cherry picked from commit 687bf5b)
7 tasks
remcowesterhoud
approved these changes
Apr 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Backport of #311 to
stable/8.0.relates to camunda-community-hub/spring-zeebe#189 #304