testcontainers / testcontainers/testcontainers-java

InternalCommandPortListeningCheck always fails for containers built without `/bin/sh`

Offen
#3,317 5 Kommentare 7 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

help wanted type/bug
Vorherrschende Sprache
Java
Sterne
8.7k
Forks
1.9k
Ø Merge
2 T. 17 Std.
Gemergte PRs (30 T.)
9

Beschreibung

Relates to #2984

I'm surprised we've not come across this earlier, but the default TCP port listening detector InternalCommandPortListeningCheck does not work for containers that do not have /bin/sh included.

This predominantly affects images built upon scratch.

The workaround/solution is to use a more application specific WaitStrategy - e.g. an HTTP wait strategy.

However the log messages don't make this easy to realise.

Given that we do both the internal and external port checks for a good reason, I don't think we can just rely on the external port check. Still perhaps we can raise a very specific error message if /bin/sh is not available inside the container.

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 InternalCommandPortListeningCheck und verfolge den Log- und Fehlerpfad, der verwendet wird, wenn einem Container /bin/sh fehlt. Reproduziere das Verhalten mit einem von scratch erstellten Image und sorge dann dafür, dass der Fehler die fehlende Shell und die betroffene Wartestrategie eindeutig angibt.

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
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

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