testcontainers / testcontainers/testcontainers-java

LogMessageWaitStrategy does not work for compose based restarting containers

Offen
#2,881 5 Kommentare 3 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

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

Hello!

The case is following:

  • testcontainers-java 1.14.3
  • docker-compose.yml with services A, B, C
  • B depends on A
  • C depends on B and A
  • withLocalCompose(true)

A starts quite quickly, B start takes ~40 seconds
While B is unavailable C keeps restarting

  • Tried Wait.forLogMessage() for A - works
  • Tried Wait.forLogMessage() for B - works
  • Tried Wait.forLogMessage() for C - Timed out waiting for log output matching <log>
  • Tried Wait.forLogMessage() for both B and C - Timed out waiting for log output matching <log>

Actually I'm interested in waiting for both of the services B and C explicitly, but only C should be valid as well.

Tried all the possible regex stuff (.*log.*, .*log.*\\s, .*log!\\s, .*log.*\n.* etc)

From my impression it seems that log polling breaks for a restarting container.
The difference between B and C here is that when starting B does not encounter broken B->A interaction since A could easily be started for the time of starting B. Hence B does not get restarted 'on error'.

As I got from debugging
https://github.com/testcontainers/testcontainers-java/blob/816b8c309ba526b4f34a9970f9f5e9918ad47d06/core/src/main/java/org/testcontainers/containers/output/WaitingConsumer.java#L85
becomes null when the container is going to start successfully, it's really strange. It contains lines from a stacktrace when the container is going to be restarted and null when it's running :suspect:

Any ideas? Thanks.

p.s. of course I see the desired log of the C in my terminal using docker logs C

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit core/src/main/java/org/testcontainers/containers/output/WaitingConsumer.java ungefähr in Zeile 85, wo der Bericht eine null-Ausgabe während des Neustarts von Containern feststellt. Reproduziere das docker-compose-Szenario mit den Services A, B und C und überprüfe anschließend, dass Wait.forLogMessage() das erwartete Log von C nach dessen Neustarts beobachten kann, ohne wegen eines Timeouts abzubrechen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
docker, docker-compose, java
Bereich
devops, testing
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
42/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.