GitLab Runner: Acelerar builds repetidos

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 disco do seu runner é persistente entre pipelines, permitindo reutilizar camadas de imagem como cache de build. Isto pode tornar builds repetidos muito mais rápidos. Eis um exemplo de configuração:

build-cached:
  stage: build
  image: docker:29
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    # Faça pull da imagem mais recente para alimentar o cache (se existir):
    - docker pull "$CI_REGISTRY_IMAGE:latest" || true
    - docker build --cache-from "$CI_REGISTRY_IMAGE:latest" -t "$CI_REGISTRY_IMAGE:latest" .
    - docker push "$CI_REGISTRY_IMAGE:latest"

Este método permite que os seus builds tirem partido do cache de camadas do Docker, reconstruindo apenas as camadas novas ou alteradas.