testcontainers / testcontainers/testcontainers-java
GenericContainer tries to talk to remote registry too soon (during instance initialization)
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Java
- Sterne
- 8.7k
- Forks
- 1.9k
- Ø Merge
- 2 T. 17 Std.
- Gemergte PRs (30 T.)
- 9
Beschreibung
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?)
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Lies core/src/main/java/org/testcontainers/containers/GenericContainer.java im Bereich des Konstruktors sowie der Einstiegspunkte setDockerImageName(), getDockerImageName() und start(). Überprüfe, dass das Erstellen eines Containers keine Verbindung zur Remote-Registry herstellt, während der Start das Image weiterhin auflöst; bestätige das Verhalten mit den relevanten vorhandenen Container-Tests.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- docker, java
- Bereich
- testing
- Issue-Typ
- Bug
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Klar beschrieben
- Anfängerfreundlichkeit
- 45/100