You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If users configure a custom ImageNameSubstitutor (for example), then this instance will get wrapped by Testcontainers when the configuration is evaluated.
If an error occurs, regardless of context (in my case, I am using Spring) then the "configured" ImageNameSubstitutor in the RemoteDockerImage instance created from an DockerImageName by the container, is quite "cryptic":
2023-05-13 02:44:13,155 ERROR g.springframework.boot.SpringApplication: 822 - Application run failed
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'CassandraContainer' defined in example.app.crm.config.TestcontainersCassandraConfiguration:
Failed to instantiate [org.testcontainers.containers.GenericContainer]: Factory method 'cassandraContainer' threw exception with message:
Can't get Docker image: RemoteDockerImage(
imageName=cassandra:3.11.15,
imagePullPolicy=DefaultPullPolicy(),
imageNameSubstitutor=org.testcontainers.utility.ImageNameSubstitutor$ChainedImageNameSubstitutor@4904144d
)
It is not apparent from this ERROR log output whether the custom ImageNameSubstitutor was actually in use here, and users have to make an effort (logging, debugging, etc) to determine if the custom ImageNameSubstitutor was actually applied or not.
In my case, I had to add logging to my "custom" ImageNameSubstitutor to determine whether it was actually being applied and used by Testcontainers during Docker Image Name resolution since my library was being built remotely in a Jenkins CI environment where debugging is nearly impossible.
Module
Core
Proposal
If users configure a custom
ImageNameSubstitutor
(for example), then this instance will get wrapped by Testcontainers when the configuration is evaluated.If an error occurs, regardless of context (in my case, I am using Spring) then the "configured"
ImageNameSubstitutor
in theRemoteDockerImage
instance created from anDockerImageName
by the container, is quite "cryptic":It is not apparent from this ERROR log output whether the custom
ImageNameSubstitutor
was actually in use here, and users have to make an effort (logging, debugging, etc) to determine if the customImageNameSubstitutor
was actually applied or not.In my case, I had to add logging to my "custom"
ImageNameSubstitutor
to determine whether it was actually being applied and used by Testcontainers during Docker Image Name resolution since my library was being built remotely in a Jenkins CI environment where debugging is nearly impossible.This:
... is quite useless.
The
toString()
method of the static innerChainedImageNameSubstitutor
class (source) could be overridden to returngetDescription()
(source).Altneratively, the
ImageNameSubstitutor
abstract class could override thetoString()
method to returngetDescription()
, like so:In this way, all extensions of
ImageNameSubstitutor
would benefit and also be consistent without any extra effort on behalf of your users.The text was updated successfully, but these errors were encountered: