Was sind die Vor- und Nachteile beim Ausführen von Anwendungstests während oder nach einem Docker-Build?

Unsere Docker-Datei erstellt die Anwendungsumgebung (z. B. env-Variablen, Installieren von Bibliotheken mit apt-get usw.). Außerdem wird der Python-Anwendungscode aus seinem Git-Repo abgerufen und kopiert.

Wir diskutieren jedoch, ob die Anwendungstests (einige Einheiten, einige Integrationen) in einen Docker- RUNBefehl (z. B. RUN /bin/bash -c "source activate cool_env; pytest") oder nach dem Build mithilfe des CI-Stacks (z. B. Jenkins, Openshift) eingefügt werden sollen, um die Tests für den erstellten Container auszuführen.

Was sind die Vor- und Nachteile von jedem?

Ich unterstütze J.Does Vorschlag für separate Docker-Dateien für jede Build- und Testphase. Ein solcher Ansatz ermöglicht Ihnen auch:

• Führen Sie die Testphase aus irgendeinem Grund erneut aus (z. B. bekannte zeitweise auftretende Fehler), ohne die Erstellungsphase erneut durchzuführen
• Führen Sie mehrere verschiedene Teststufen parallel mit demselben Build aus - beispielsweise anstatt eine einzelne lange Teststufe aus serialisierten Tests auszuführen, um eine potenziell signifikante Beschleunigung der gesamten Pipeline zu erzielen.

Wenn Sie alles im selben Container ausführen ...

PRO: Sie haben die CasC-Herausforderung für die Inline-Konfiguration der Testumgebung gelöst

CON: Sie vermissen den Blackbox-Testteil. Stellen Sie sich vor, Ihr Container würde keine Verbindungen von außen akzeptieren. Autsch!

Mögliche Lösung: Ich würde mich daher für eine mehrstufige deklarative Docker-basierte Pipeline entscheiden: eine Docker-Umgebung für jede Phase, in der Artefakte entlang kaskadieren.