GitLab: Running your tests with Testcontainers

This documentation is part of the CI/CD guide. You can view the complete guide here: How to use GitLab CI/CD.

👋 Welcome to the Stackhero documentation!

Stackhero offers a ready-to-use GitLab cloud solution designed for teams seeking a fast, secure, and scalable environment:

• Unlimited users, repositories, data transfers, and CI/CD processing time for complete flexibility.
• Effortless updates with a single click, keeping your environment up to date with no downtime.
• Custom domain name secured with HTTPS (for example, https://git.your-company.com) for a professional image and enhanced security.
• Consistent performance and robust security on your own private, dedicated infrastructure. No noisy neighbours and full isolation guaranteed.
• Choice of hosting location: 🇪🇺 Europe or 🇺🇸 USA to meet your compliance or latency requirements.

Get started quickly and focus on your code. Stackhero's GitLab cloud hosting solution is up and running in about 5 minutes.

If your test suite uses Testcontainers, a library that launches real services (databases, message brokers, etc.) as disposable Docker containers during test execution, the configuration above is already suitable. Keep the docker:29-dind service and both variables: Testcontainers uses DOCKER_HOST to access the Docker daemon and connect to the containers it starts, so no further configuration is required.

Omitting DOCKER_HOST is the most common cause of Testcontainers failures in CI. The library then falls back to the Docker socket mounted by the runner and cannot access its own test containers, which usually results in a timeout of the Ryuk helper container.