Using a single scrape attempt that is protected by Awaitility should
protect against instability of the OpenTelemetry Collector instance
running in the container and will hopefully stabilize the test.
This commit has also increased the timeout for a successful response
to 30 seconds and removed the configuration of the configuration of
the polling delay and interval as the values being set were the same
as the defaults.
Closes gh-42377
Replace `DockerImageNames` with a enum and relocate it from the
`testcontainers` to `container` package. The enum now also
becomes a common location that we can use to apply container
configuration such as timeouts.
Closes gh-41164
Co-authored-by: Phillip Webb <phil.webb@broadcom.com>
Prior to this commit, a Testcontainer that was managed as a bean
would not have been started in time if it was accessed before
the bean factory's configuration had been frozen. A common way
for this to occur is when using JPA. The entity manager factory
bean is LoadTimeWeaverAware which causes it to be created before
configuration is frozen. Creating this bean requires the DataSource
which in turn requires the JdbcConnectionDetails and its JDBC URL.
Getting the JDBC URL From the connection details requires the
container hosting the SQL database to have been started.
This commit updates ContainerConnectionDetails, the super-class for
all Testcontainer-based ConnectionDetails implementations, to publish
an event when the Container is retrieved from the details. When this
event is published, TestcontainersLifecycleBeanPostProcessor
initializes all containers that are defined as beans.
Closes gh-40585
Update `TestcontainersLifecycleBeanPostProcessor` so that containers
are now initialized either on the first `postProcessAfterInitialization`
call with a frozen configuration or just before a test container
property is supplied.
Prior to this commit, it was assumed that the first post-process call
after the configuration was frozen was suitably early to initialize
the containers. This turns out to not be no always the case.
Specifically, in the `finishBeanFactoryInitialization` method of
`AbstractApplicationContext` we see that `LoadTimeWeaverAware` beans
are obtained before the configuration is frozen. One such bean is
`DefaultPersistenceUnitManager` which is likely to need datasource
properties that will require a started container.
To fix the problem, the `TestcontainersPropertySource` now publishes
a `BeforeTestcontainersPropertySuppliedEvent` to the ApplicationContext
just before any value is supplied. By listening for this event, we can
ensure that containers are initialized and started before any dynamic
property is read.
Fixes gh-38913
Update `TestcontainersLifecycleBeanPostProcessor` so that containers
can actually be started in parallel.
Prior to this commit, `initializeStartables` would collect beans
and in the process trigger the `postProcessAfterInitialization` method
on each bean. This would see that `startablesInitialized` was `true`
and call `startableBean.start` directly. The result of this was that
beans were actually started sequentially and when the `start` method
was finally called it had nothing to do.
The updated code uses an enum rather than a boolean so that the
`postProcessAfterInitialization` method no longer attempts to start
beans unless `initializeStartables` has finished.
Fixes gh-38831
Update `TestcontainersLifecycleBeanPostProcessor` to restore early
container initialization logic and refine startup logic. Initial bean
access now again triggers the creation all container beans. In addition
the first access of a `Startable` bean now attempts to find and start
all other `Startable` beans.
Fixes gh-37989
Add support for a `spring.testcontainers.startup` property that can
be set to "sequential" or "parallel" to change how containers are
started.
Closes gh-37073
