GitLab Runner: Exécuter vos tests avec Testcontainers

Cette documentation fait partie du guide Création d’images Docker. Consultez le guide complet ici : Construisez et poussez efficacement des images Docker à partir de vos pipelines GitLab CI/CD en utilisant les runners Stackhero et Docker-in-Docker.

👋 Bienvenue dans la documentation Stackhero !

Stackhero offre une solution GitLab Runner cloud simple qui rend l’exécution de vos jobs GitLab CI/CD efficace et sans tracas. Voici ce que vous pouvez attendre :

• Minutes CI/CD illimitées : exécutez vos pipelines aussi souvent que nécessaire, sans facturation à la minute ni frais imprévus.
• Plusieurs jobs simultanés : accélérez votre développement en lançant plusieurs jobs en parallèle.
• L’executor Docker avec prise en charge de Docker-in-Docker : construisez et poussez facilement des images de conteneurs dans vos processus CI/CD.
• Fonctionne parfaitement avec GitLab.com et les instances GitLab autogérées.
• Une infrastructure privée et dédiée avec stockage NVMe/SSD rapide assure des performances de build stables et prévisibles.
• Disponible dans les régions 🇪🇺 Europe et 🇺🇸 USA pour répondre aux besoins de votre équipe.

Gagnez du temps : connectez votre premier GitLab Runner et commencez à exécuter vos pipelines en quelques minutes seulement !

Testcontainers est une bibliothèque de tests, disponible pour Java, Go, Node.js, Python, .NET et d’autres langages, qui démarre de vrais services sous forme de conteneurs Docker jetables pendant l’exécution de vos tests. Plutôt que de simuler une base de données ou un message broker, vos tests d’intégration communiquent avec une véritable instance PostgreSQL, MySQL, Redis ou Kafka, créée avant les tests et supprimée juste après. C’est particulièrement populaire dans les projets Java et Spring.

Testcontainers a besoin d’un démon Docker, donc il fonctionne avec exactement la même configuration Docker-in-Docker que ci-dessus. Aucune variable supplémentaire n’est requise :

test:
  stage: test
  # Utilisez l’image dont vos tests ont besoin (ici un JDK), pas forcément l’image docker :
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

Testcontainers lit la variable DOCKER_HOST pour trouver le démon, et il réutilise ce même hostname docker pour accéder aux ports exposés par les conteneurs qu’il démarre. Les deux fonctionnent car l’alias docker est résolu sur le réseau du job.

Gardez la variable DOCKER_HOST dans vos jobs Testcontainers. Sans elle, Testcontainers utilise le socket Docker monté par le runner, puis tente d’atteindre vos conteneurs de test via l’adresse IP de l’hôte, à laquelle votre job ne peut pas accéder. Le symptôme classique est l’échec du conteneur helper Ryuk avec Wait strategy failed. Container is removed, ou Timed out waiting for log output matching '.*Started.*'.