GitLab Runner: Tests mit Testcontainers ausführen

Diese Dokumentation ist Teil des Docker-Images bauen-Leitfadens. Den vollständigen Leitfaden finden Sie hier: Bauen und pushen Sie Docker-Images effizient aus Ihren GitLab CI/CD-Pipelines mit Stackhero Runnern und Docker-in-Docker.

👋 Willkommen in der Stackhero-Dokumentation!

Stackhero bietet Ihnen eine unkomplizierte GitLab Runner Cloud-Lösung, mit der Sie Ihre GitLab CI/CD-Jobs effizient und ohne Aufwand ausführen können. Das erwartet Sie:

• Unbegrenzte CI/CD-Minuten: Führen Sie Ihre Pipelines so oft aus, wie Sie möchten – ohne Abrechnung pro Minute oder unerwartete Zusatzkosten.
• Mehrere gleichzeitige Jobs: Beschleunigen Sie Ihre Entwicklung, indem Sie mehrere Jobs parallel ausführen.
• Der Docker Executor mit Docker-in-Docker-Unterstützung: Erstellen und pushen Sie Container-Images ganz einfach als Teil Ihres CI/CD-Prozesses.
• Funktioniert nahtlos mit GitLab.com und self-managed GitLab-Instanzen.
• Eine private, dedizierte Infrastruktur mit schneller NVMe/SSD-Speicherung sorgt für stabile und vorhersehbare Build-Performance.
• Verfügbar in den Regionen 🇪🇺 Europa und 🇺🇸 USA, passend zu den Anforderungen Ihres Teams.

Sparen Sie Zeit: Sie können Ihren ersten GitLab Runner verbinden und bereits nach wenigen Minuten mit Ihren Pipelines starten!

Testcontainers ist eine Testbibliothek, verfügbar für Java, Go, Node.js, Python, .NET und weitere Sprachen, die während Ihrer Tests echte Services als temporäre Docker-Container startet. Anstatt eine Datenbank oder einen Message-Broker zu mocken, kommunizieren Ihre Integrationstests mit einer echten PostgreSQL-, MySQL-, Redis- oder Kafka-Instanz, die vor den Tests erstellt und danach wieder entfernt wird. Besonders beliebt ist Testcontainers in Java- und Spring-Projekten.

Testcontainers benötigt einen Docker-Daemon und läuft daher mit exakt derselben Docker-in-Docker-Konfiguration wie oben. Es sind keine zusätzlichen Variablen erforderlich:

test:
  stage: test
  # Verwenden Sie das Image, das Ihre Tests benötigen (hier ein JDK), nicht zwingend das Docker-Image:
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

Testcontainers liest DOCKER_HOST, um den Daemon zu finden, und verwendet denselben docker-Hostnamen, um auf die von den Containern veröffentlichten Ports zuzugreifen. Beides funktioniert, da der Alias docker im Netzwerk Ihres Jobs aufgelöst wird.

Belassen Sie DOCKER_HOST in Ihren Testcontainers-Jobs. Ohne diese Variable greift Testcontainers auf den vom Runner gemounteten Docker-Socket zurück und versucht dann, Ihre Testcontainer über die Host-IP-Adresse zu erreichen, was aus dem Job heraus nicht möglich ist. Typische Symptome sind, dass der Ryuk-Helfercontainer mit Wait strategy failed. Container is removed oder Timed out waiting for log output matching '.*Started.*' fehlschlägt.