GitLab Runner: Uw tests uitvoeren met Testcontainers

Deze documentatie maakt deel uit van de Docker-images bouwen-gids. Bekijk de volledige gids hier: Bouw en push Docker-images efficiënt vanuit uw GitLab CI/CD-pipelines met Stackhero runners en Docker-in-Docker.

👋 Welkom bij de Stackhero-documentatie!

Stackhero biedt een eenvoudige GitLab Runner cloud oplossing waarmee u uw GitLab CI/CD-jobs efficiënt en zonder gedoe kunt uitvoeren. Dit kunt u verwachten:

• Onbeperkte CI/CD-minuten: voer uw pijplijnen zo vaak uit als nodig, zonder kosten per minuut of onverwachte extra kosten.
• Meerdere gelijktijdige jobs: versnel uw ontwikkeling door verschillende jobs parallel uit te voeren.
• De Docker executor met ondersteuning voor Docker-in-Docker: bouw en push eenvoudig container images als onderdeel van uw CI/CD-proces.
• Werkt naadloos met zowel GitLab.com als self-managed GitLab-omgevingen.
• Een privé, dedicated infrastructuur met snelle NVMe/SSD-opslag zorgt voor stabiele en voorspelbare build-prestaties.
• Beschikbaar in de regio's 🇪🇺 Europa en 🇺🇸 USA om aan de behoeften van uw team te voldoen.

Bespaar tijd: u kunt uw eerste GitLab Runner koppelen en binnen enkele minuten starten met het uitvoeren van pijplijnen!

Testcontainers is een testbibliotheek, beschikbaar voor Java, Go, Node.js, Python, .NET en andere talen, die echte services als tijdelijke Docker-containers opstart tijdens het uitvoeren van uw tests. In plaats van bijvoorbeeld een database of message broker te mocken, communiceren uw integratietests met een echte PostgreSQL-, MySQL-, Redis- of Kafka-instantie, die vóór de tests wordt aangemaakt en direct erna weer wordt verwijderd. Het is vooral populair in Java- en Spring-projecten.

Testcontainers heeft een Docker-daemon nodig en werkt dus met exact dezelfde Docker-in-Docker-configuratie als hierboven. Er is geen extra variabele nodig:

test:
  stage: test
  # Gebruik het image dat uw tests nodig hebben (hier een JDK), niet per se het 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 leest DOCKER_HOST om de daemon te vinden en gebruikt dezelfde docker hostname om de poorten te bereiken die door de containers worden gepubliceerd. Beide werken zelfstandig, omdat het docker alias op het netwerk van uw job wordt opgelost.

Houd DOCKER_HOST in uw Testcontainers-jobs. Zonder deze variabele valt Testcontainers terug op de Docker-socket die door de runner is gemount, en probeert vervolgens uw testcontainers te bereiken via het host-IP-adres, waar uw job geen verbinding mee kan maken. Het gebruikelijke symptoom is dat de Ryuk-helpercontainer faalt met Wait strategy failed. Container is removed, of Timed out waiting for log output matching '.*Started.*'.