Novos betas do GitLab: métricas de jobs e Container Virtual Registry

Dois recursos em beta recentes merecem atenção de equipes de plataforma e DevOps: as Métricas de desempenho de Jobs e o Container Virtual Registry. O objetivo de ambos é o mesmo — reduzir gargalos de CI/CD ao oferecer visibilidade de performance de Jobs e centralizar o pull e o caching de imagens de container, sem a necessidade de introduzir ferramentas terceiras adicionais. Na prática, são os dois pontos onde mais perdemos tempo no dia a dia: descobrir qual Job está degradando o tempo de Pipeline e lidar com falhas intermitentes de pull de imagem. Este post detalha o que cada recurso entrega hoje, como habilitá-los com segurança e como interpretar os números antes de sair otimizando no escuro.

Métricas de desempenho de Jobs do GitLab

As Métricas de desempenho de Jobs fornecem um painel por Job, acessível na página de CI/CD analytics do Project, para responder rapidamente a perguntas operacionais críticas: quais Jobs ficaram mais lentos (comparando P50 vs P95), quais apresentam maior taxa de falha e em qual Stage estão atuando.

O painel exibe os últimos 30 dias por padrão e oferece ordenação, pesquisa por nome do Job e paginação — eliminando a necessidade de dashboards customizados ou buscas manuais em logs para perguntas básicas de desempenho.

Por que P50 vs P95 importa (e não a média)

A maior armadilha em análise de duração de Job é olhar para a média. A média esconde a cauda longa — exatamente onde mora o problema que trava o time. Por isso o painel trabalha com percentis:

• P50 (mediana): metade das execuções terminou abaixo desse tempo. É o seu "caso típico".
• P95: 95% das execuções terminaram abaixo desse tempo. Os 5% restantes são os piores casos que seus desenvolvedores realmente sentem ao esperar um merge request.

O sinal mais útil não é o valor absoluto, e sim o gap entre P50 e P95. Um Job com P50 de 2 min e P95 de 3 min é estável. Um Job com P50 de 2 min e P95 de 14 min é instável — algo introduz variância: contenção de runner, cache miss intermitente, dependência externa lenta ou um teste flaky que ocasionalmente faz retry. Esse Job é o seu candidato número um à investigação, mesmo que a média pareça "aceitável".

Sinal observado	Leitura provável	Primeira ação
P50 alto, P95 próximo do P50	Job consistentemente lento (problema estrutural)	Otimizar a etapa em si: cache, paralelização, imagem menor
P50 baixo, P95 muito acima	Variância / instabilidade	Investigar runners, dependências externas, flakiness
Taxa de falha alta + P95 alto	Retries mascarando o problema	Revisar retry, isolar testes não determinísticos
Tendência de subida do P95 ao longo de 30 dias	Regressão recente	Correlacionar com mudanças no .gitlab-ci.yml ou na imagem base

Disponibilidade e requisitos técnicos

O recurso está disponível para GitLab Premium e Ultimate em status de beta de disponibilidade limitada no GitLab.com. Também está disponível no Self-Managed e no GitLab Dedicated quando o ClickHouse está configurado. A meta é permitir que equipes de platform engineering detectem regressões de duração de Jobs e Jobs instáveis (flaky) diretamente no ambiente onde já monitoram Pipelines.

A dependência de ClickHouse no Self-Managed não é detalhe trivial: as métricas agregadas por percentil sobre toda a janela de 30 dias exigem um store analítico. Se você opera GitLab autogerenciado e ainda não tem ClickHouse provisionado, esse é o pré-requisito a planejar antes de esperar ver o painel populado.

Como acessar (passo a passo)

1. Acesse o Project no GitLab.
2. Selecione Analyze > CI/CD analytics.
3. Localize o painel CI/CD job performance metrics e ordene por duração ou taxa de falha para identificar candidatos a otimização.

Reduzindo a duração depois de identificar o culpado

O painel aponta onde está o gargalo; a remediação continua sendo trabalho de engenharia. Algumas alavancas concretas, em ordem aproximada de custo-benefício:

1. Cache de dependências. O cache miss é uma das maiores fontes de variância no P95. Defina chaves de cache estáveis e baseadas no lockfile, não no branch:

build:
  stage: build
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - node_modules/
    policy: pull-push
  script:
    - npm ci
    - npm run build

2. Paralelização. Suítes de teste longas são candidatas naturais a sharding com parallel:

test:
  stage: test
  parallel: 4
  script:
    - ./run-tests.sh --shard "$CI_NODE_INDEX/$CI_NODE_TOTAL"

3. Disciplinar o retry. Retry automático é útil, mas mascara flakiness e infla a duração média. Restrinja a falhas que realmente são transitórias em vez de aplicar retry: 2 globalmente:

deploy:
  stage: deploy
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure
  script:
    - ./deploy.sh

Próximos passos no roadmap

O roadmap imediato prevê agrupamento em nível de Stage para agregação de métricas por build, test e deploy, facilitando a priorização de ações de otimização. Equipes de platform engineering devem correlacionar aumentos de P95 com mudanças recentes nas Pipelines antes de remediar; as métricas reduzem significativamente o tempo de investigação.

Uma rotina prática: antes de abrir uma issue de otimização, verifique se o salto de P95 coincide com um commit no .gitlab-ci.yml, uma atualização da imagem base ou uma mudança de capacidade de runners. Otimizar um Job que regrediu por causa de uma imagem inchada é desperdício — corrija a causa, não o sintoma.

Container Virtual Registry

O Container Virtual Registry centraliza os pulls de imagens ao criar um endpoint único no GitLab que resolve e aplica pull-through caching de múltiplos registries upstream — Docker Hub, Harbor, Quay e outros compatíveis com long-lived tokens. O resultado é a redução do overhead operacional relacionado a autenticação múltipla, disponibilidade e largura de banda, além de menor fragilidade nas Pipelines causada por dependências externas.

O problema que ele resolve

Quem mantém muitas Pipelines conhece a dor: cada Job que faz docker pull de um registry externo é um ponto de falha. O Docker Hub aplica limites de taxa em pulls anônimos e autenticados; um pico de Pipelines simultâneas pode esbarrar nesse limite e quebrar builds que não têm relação nenhuma com a mudança em teste. Some a isso as credenciais espalhadas por dezenas de projetos e a indisponibilidade ocasional de um registry terceiro, e você tem uma classe inteira de falhas vermelhas que não são culpa do código.

O pull-through cache ataca isso de frente: o GitLab faz o pull do upstream uma vez, guarda em cache e serve todas as execuções subsequentes a partir dele. Em vez de N projetos autenticando em N registries, você configura o upstream uma vez e aponta as Pipelines para o endpoint virtual.

Como referenciar nas Pipelines

Depois de configurado, o consumo é só uma troca de referência de imagem — você substitui o caminho do registry público pelo endpoint virtual do seu Project/Group:

build:
  stage: build
  image: registry.example.com/meu-grupo/virtual/library/node:20
  script:
    - node --version
    - npm ci

O ganho operacional aparece sem mudar a lógica do Job: o primeiro pull aquece o cache; do segundo em diante, a imagem vem do GitLab, mais perto dos runners e sem depender da disponibilidade do upstream.

Estado do beta e suporte atual

O recurso está em beta com API disponível a partir da versão 18.9. Suporta atualmente registries com autenticação por token de longa duração e pull-through caching. Registros de provedores cloud que exigem IAM — como ECR, Google Artifact Registry e ACR — estão sendo avaliados para iterações futuras.

No SaaS (GitLab.com), o acesso é por solicitação ao CSM ou por comentário na issue de feedback. No Self-Managed, a configuração é realizada via feature flag e API.

Cenário	Suportado hoje (beta)
Docker Hub, Harbor, Quay (long-lived token)	Sim
Pull-through caching	Sim
ECR, Google Artifact Registry, ACR (IAM)	Em avaliação para iterações futuras
Acesso no GitLab.com	Por solicitação ao CSM ou comentário na issue de feedback
Configuração no Self-Managed	Via feature flag e API

Benefícios práticos para times B2B e DevOps

A adoção do Container Virtual Registry traz ganhos diretos em três frentes. Operacionalmente, reduz a quantidade de credenciais a configurar por Pipeline e diminui o risco de falhas por indisponibilidade de um registry externo. Em custo e desempenho, imagens servidas do cache GitLab após o primeiro pull reduzem latência e consumo de banda. Em governança, a centralização de políticas de imagens e a observabilidade dos pulls apoiam avaliações de consolidação do GitLab como registry único da organização.

Trade-offs a considerar antes de adotar

Nenhum recurso é gratuito. Pontos a pesar antes de levar para produção:

• É beta. A API a partir da 18.9 pode mudar, e a falta de suporte a IAM hoje é bloqueante se sua frota de imagens vive em ECR, Artifact Registry ou ACR. Avalie se seus registries atuais usam token de longa duração.
• Armazenamento e invalidação. Pull-through cache consome espaço e exige política clara de retenção e atualização. Confie demais em tags mutáveis (como latest) e você pode servir uma imagem desatualizada do cache — prefira tags imutáveis ou digests em produção.
• Ponto único de dependência. Centralizar pulls no GitLab simplifica credenciais, mas concentra risco: se o endpoint virtual estiver indisponível, ele afeta mais Pipelines de uma vez. Vale dimensionar e monitorar esse caminho como infraestrutura crítica.

Testes e feedback

Como ambos os recursos estão em beta, recomenda-se ativá-los em ambientes de staging ou Pipelines paralelas antes de adotar em produção. Reporte problemas e sugestões nas issues de feedback vinculadas ao release do GitLab. A participação dos times é decisiva para a priorização de itens como o agrupamento por Stage (para métricas) e o suporte a autenticação IAM (para o registry).

Checklist de rollout seguro

1. Confirme os pré-requisitos. Premium/Ultimate para as métricas; ClickHouse configurado no Self-Managed; versão 18.9 ou superior para a API do registry.
2. Habilite em escopo restrito. Comece por um Project ou Group não crítico. No Self-Managed, use a feature flag; no GitLab.com, solicite acesso ao CSM ou via issue de feedback.
3. Rode Pipelines paralelas. Para o registry, mantenha a referência antiga e a nova lado a lado e compare confiabilidade dos pulls antes de migrar de vez.
4. Estabeleça uma baseline. Deixe as métricas acumularem dados por alguns dias antes de tirar conclusões — percentis precisam de volume de execuções para serem confiáveis.
5. Defina critério de saída do beta. Decida antecipadamente o que precisa ser verdade (estabilidade, suporte a IAM, etc.) para promover o uso a produção.
6. Reporte. Documente atritos nas issues de feedback — é assim que itens como agrupamento por Stage e IAM sobem na fila de prioridade.

Conclusão

Valide as métricas em Pipelines reais e utilize o Container Virtual Registry para reduzir dependências externas nas execuções de CI. Esses dois betas representam mudanças operacionais relevantes para equipes de plataforma e DevOps que buscam maior previsibilidade e menor tempo gasto em troubleshooting de Pipelines. O fio condutor de ambos é o mesmo: transformar perguntas que antes exigiam escavação manual em logs — "qual Job degradou?" e "por que esse pull falhou?" — em respostas diretas dentro do próprio GitLab.

Quer adotar esses recursos com segurança no seu fluxo de CI/CD? Vamos conversar.

Referência: post original no blog do GitLab.