GitLab Runner: Executar os seus testes com Testcontainers

Esta documentação faz parte do guia Construir imagens Docker. Consulte o guia completo aqui: Construa e envie imagens Docker de forma eficiente a partir dos seus pipelines GitLab CI/CD utilizando runners Stackhero e Docker-in-Docker.

👋 Bem-vindo à documentação da Stackhero!

A Stackhero disponibiliza uma solução GitLab Runner cloud simples que torna a execução dos seus jobs GitLab CI/CD eficiente e sem complicações. Eis o que pode esperar:

• Minutos CI/CD ilimitados: execute os seus pipelines sempre que precisar, sem cobrança por minuto nem custos inesperados.
• Vários jobs em simultâneo: acelere o desenvolvimento ao executar múltiplos jobs em paralelo.
• O executor Docker com suporte para Docker-in-Docker: construa e faça push de imagens de containers facilmente como parte do seu processo CI/CD.
• Compatível tanto com GitLab.com como com instâncias GitLab self-managed.
• Uma infraestrutura privada e dedicada com armazenamento NVMe/SSD rápido garante um desempenho de build estável e previsível.
• Disponível nas regiões 🇪🇺 Europa e 🇺🇸 USA para responder às necessidades da sua equipa.

Poupe tempo: pode ligar o seu primeiro GitLab Runner e começar a executar pipelines em apenas alguns minutos!

O Testcontainers é uma biblioteca de testes, disponível para Java, Go, Node.js, Python, .NET e outras linguagens, que inicia serviços reais como contentores Docker descartáveis durante a execução dos seus testes. Em vez de simular uma base de dados ou um message broker, os seus testes de integração comunicam com uma instância real de PostgreSQL, MySQL, Redis ou Kafka, criada antes dos testes e removida logo após. É especialmente popular em projetos Java e Spring.

O Testcontainers necessita de um daemon Docker, pelo que funciona exatamente com a mesma configuração Docker-in-Docker apresentada acima. Não é necessária nenhuma variável adicional:

test:
  stage: test
  # Utilize a imagem necessária para os seus testes (um JDK neste caso), não necessariamente a imagem docker:
  image: gradle:jdk21
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  script:
    - gradle test

O Testcontainers lê a variável DOCKER_HOST para encontrar o daemon e reutiliza o mesmo hostname docker para aceder às portas publicadas pelos contentores que inicia. Ambos funcionam de forma autónoma, pois o alias docker é resolvido na rede do seu job.

Mantenha o DOCKER_HOST nos seus jobs com Testcontainers. Sem esta variável, o Testcontainers recorre ao socket Docker montado pelo runner e tenta aceder aos seus contentores de teste através do endereço IP do host, ao qual o seu job não consegue ligar-se. O sintoma mais comum é o contentor auxiliar Ryuk falhar com Wait strategy failed. Container is removed, ou Timed out waiting for log output matching '.*Started.*'.