GenericContainer tries to talk to remote registry too soon (during instance initialization)
还没有人认领这个 Issue。
评估
调研方向
阅读 core/src/main/java/org/testcontainers/containers/GenericContainer.java 中 constructor 以及 setDockerImageName()、getDockerImageName() 和 start() 入口点附近的代码。验证构造 container 时不会联系远程 registry,同时启动时仍会解析 image;使用相关的现有 container 测试确认该行为。
由索引模型根据 Issue 内容生成。
描述
I'm running tests on a machine that doesn't currently have connectivity to the Docker Hub. Certainly, I expect TestContainer-based cases to fail in that case. So I have written a JUnit rule to conditionally disable these test cases when a certain configuration setting has been made, and write something like this in my test case:
public static ConditionalIgnore skip =
ConditionalIgnore.needsDocker(ConfigFactory.load("test"));
// VaultContainer is my own subclass of GenericContainer
public static VaultContainer VAULT = new VaultContainer();
@ClassRule
public static final RuleChain rules = RuleChain.outerRule(skip)
.around(VAULT);
The problem I'm seeing is, however, that this requires instantiating the VaultContainer class, which will call the GenericContainer constructors, and those constructors will actually try to talk to the Docker Hub:
Caused by: org.testcontainers.containers.ContainerFetchException: Can't get Docker image name from org.testcontainers.images.RemoteDockerImage@4a0952ab
at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:711)
at org.testcontainers.containers.GenericContainer.setDockerImageName(GenericContainer.java:699)
at org.testcontainers.containers.GenericContainer.<init>(GenericContainer.java:145)
at com.progressfin.foundation.secret.VaultContainer.<init>(VaultContainer.java:33)
at com.progressfin.foundation.secret.VaultContainer.<init>(VaultContainer.java:29)
at com.progressfin.foundation.secret.VaultSecretsTest.<clinit>(VaultSecretsTest.java:30)
... 40 more
Caused by: org.testcontainers.shaded.com.github.dockerjava.api.exception.InternalServerErrorException: {"message":"Get https://registry-1.docker.io/v2/: read tcp 1.2.3.4:54526->4.3.2.1:443: read: connection reset by peer"}
The problem is here (line numbers don't match up because the stack trace is from 1.1.6):
There's a very interesting comment there ("Mimic old behavior where we resolve image once it's set") that tells us that this behavior is intentional. What I would suggest is that the behavior is at odds with the sort of uses that JUnit rules are meant to support; the test rule should arguably take no "risky" actions at all unless the Statement is actually invoked, i.e. in the GenericContainer.start() method, which already does call the getDockerImageName() method anyway. (And is it just me, or is it also weird that a String getter like getDockerImageName() would talk to the network?)
- 主要语言
- Java
- 星标
- 8.7k
- 派生
- 1.9k
- 平均合并
- 2 天 17 小时
- 30 天内合并 PR
- 9
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
testcontainers/testcontainers-java 的其他 Issue
-
type/bug
难度 2/5 1-3 小时 新手友好度 78/100
testcontainers/testcontainers-java#11997 · 1 条评论 ·
-
[Enhancement]: Document why singleton containers are required under Spring's test context caching 未关闭type/enhancement
难度 1/5 1 小时以内 新手友好度 85/100
testcontainers/testcontainers-java#11967 ·
-
type/bug
难度 2/5 1-3 小时 新手友好度 78/100
testcontainers/testcontainers-java#11941 ·
-
type/bug
难度 2/5 1-3 小时 新手友好度 74/100
testcontainers/testcontainers-java#11829 · 1 条评论 ·
-
type/enhancement
难度 2/5 1-3 小时 新手友好度 65/100
testcontainers/testcontainers-java#11578 ·
查看 testcontainers/testcontainers-java 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 76/100
-
bug needs triage
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 1/5 1 小时以内 新手友好度 94/100
objectionary/hone-maven-plugin#1061 ·
-
难度 2/5 1-3 小时 新手友好度 76/100
spring-projects/spring-modulith#1895 ·