Buildkite libera segredos escopados e ferramentas MCP para IA no CI/CD

Segredos presos ao pipeline, não ao cluster inteiro

A Buildkite anunciou em 19 de outubro de 2026, segundo reportagem da InfoQ, uma nova visão de segredos dentro de Pipeline settings. Ela permite criar "pipeline secrets": segredos de cluster cujo acesso fica restrito ao pipeline atual, em vez de aparecerem na interface geral do cluster, visível a todos os pipelines que o usam. É possível adicionar condições por branch, queue, origem do build ou quem criou o build, e o valor do segredo some da tela assim que é salvo.

Segredos de pipeline são segredos de cluster restritos ao pipeline atual, e condições de branch, queue, origem do build ou criador reduzem ainda mais o acesso.

Pipeline secrets are cluster secrets restricted to the current pipeline, and branch, queue, build source, or creator conditions narrow access further.Matt Mejia, no anúncio da Buildkite

Para criar ou editar esses segredos é preciso ter permissão tanto no pipeline quanto no gerenciamento do cluster. Pipelines que usam o compatibility layer de GitHub Actions passam a exibir um aviso, antes do primeiro workflow rodar, apontando para a configuração de segredos.

Escopo reduzido não dispensa cuidado dentro do step

Separar segredos por pipeline reduz o raio de exposição de um vazamento, mas a própria Buildkite reconhece, na documentação citada pela InfoQ, que isso não substitui o cuidado de expor cada segredo só aos steps que realmente precisam dele. A InfoQ já tinha relatado, em 2025, a HashiCorp defendendo gerenciamento de segredos "prevention-first" em ferramentas de desenvolvimento e sistemas de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, e esse é o mesmo problema que a Buildkite ataca agora pelo lado da interface.

O pacote de mudanças traz mais pontas soltas de segurança amarradas. A CLI da Buildkite ganhou um comando para migrar segredos do GitHub Actions, e a versão 3.59.1 corrige o tratamento de caminhos relativos de workflow durante essa migração. O Agent v4.0.9 passa a ocultar tokens da Buildkite por prefixo nos logs de job, e o v4.0.8 oculta erros capturados de job usando os segredos já registrados para aquele job.

Um servidor MCP para validar, comparar e consertar pipelines

A parte mais extensa do anúncio é a atualização do servidor MCP↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → da Buildkite, pensado para dar a agentes de IA ferramentas específicas de CI em vez de forçá-los a interpretar logs inteiros ou montar chamadas de API de baixo nível. A ferramenta validate_pipeline checa a sintaxe e a estrutura do YAML do pipeline contra o schema oficial da Buildkite sem subir o arquivo nem disparar um build, retornando caminhos e mensagens de erro que um agente de codificação pode usar para corrigir steps inválidos. Ela não cobre interpolação de variável de ambiente, configuração de plugin, referências entre dependências nem steps gerados dinamicamente.

A segunda ferramenta, compare_builds, compara um build que falhou com o build anterior mais recente que passou na mesma branch, ou com outro build escolhido manualmente. Ela aponta quais steps passaram a falhar, quais se recuperaram e quais continuam quebrados, junto com mudanças em tempo de execução e retentativas; para até três steps recém-quebrados, traz o fim do log do job como contexto imediato de diagnóstico. Como resume a cobertura da InfoQ, só ter acesso ao log não é suficiente para depurar um build, e é exatamente essa lacuna que compare_builds tenta fechar, dando ao agente um ponto de comparação em vez de um despejo de texto.

O release de MCP também adiciona rastros de execução do Test Engine e consultas das execuções mais lentas, e traz a ferramenta create_pipeline_webhook, que adiciona um webhook do GitHub que está faltando em um pipeline já existente, evitando recriá-lo do zero.

Breaking change para quem automatiza o MCP

A versão 1.23.0 do servidor mudou o comportamento de create_pipeline: agora é obrigatório informar explicitamente create_webhook, o que quebra integrações que chamavam essa ferramenta sem esse parâmetro. Times que automatizaram a criação de pipelines via MCP precisam revisar esses scripts antes de atualizar.

A Buildkite também reverteu uma decisão de design depois de rodar avaliações: resumos de falha voltaram a incluir jobs que nunca chegaram a rodar, porque deixar isso opcional fazia os agentes emitirem chamadas de ferramenta extras para descobrir a mesma informação. É um detalhe pequeno, mas mostra a empresa ajustando a API do MCP com base em como os agentes de fato se comportam, não em como a equipe imaginou que eles se comportariam. Conexões MCP remotas agora também podem ser fixadas em uma única organização Buildkite direto na URL do servidor, tanto para a URL completa quanto para a somente leitura.

O que muda pra quem constrói pipeline aqui

Na prática, um agente de codificação ganha condições de rodar validate_pipeline antes do commit, pegando erro de sintaxe no YAML do pipeline sem gastar um build de CI inteiro só para descobrir que faltou uma aspa. Depois que algo quebra, compare_builds dá ao agente, e a quem está de plantão, um diff estruturado entre o build com problema e o último que passou, em vez de obrigar alguém a rolar duzentas linhas de log atrás do que mudou.

Vale o mesmo alerta que a InfoQ já fez para fluxos agentic no GitHub: dar a um agente ferramentas que criam webhook ou criam pipeline é dar a ele permissão de alterar a configuração de CI. O modelo de permissões restritas, execução isolada e ações auditáveis que a InfoQ descreveu para workflows agentic no GitHub vale também aqui, especialmente para quem planeja deixar o MCP rodar sem supervisão humana em cada chamada.

arm64 chega à camada de compatibilidade com GitHub Actions

A camada de compatibilidade que roda workflows de GitHub Actions dentro da Buildkite agora suporta agentes Linux arm64 tanto para o importer quanto para os jobs gerados. Labels como ubuntu-24.04-arm exigem um mapeamento explícito de queue e não caem de volta para x86-64 nem usam emulação, o que importa para quem mantém frota arm64 (instâncias Graviton na AWS, por exemplo) e quer manter essa arquitetura ao trazer workflows do GitHub Actions para a Buildkite.

O pacote de compatibilidade também corrige valores de ambiente, segredos nomeados, variáveis de runtime e valores de matrix em configuração de service-container, expõe mais valores de strategy.* para expressões de job e step, e eleva o limite de arquivos alterados usado pelos filtros de path de 300 para 3.000, útil para monorepos grandes que antes esbarravam nesse teto.

Mais telemetria no Agent v4.1.0

O Agent v4.1.0 adiciona duração e tamanho de salvamento e restauração de cache à telemetria da Buildkite, e os spans de job do OpenTelemetry agora incluem commit, pull request e autor do build. São campos a mais para quem já instrumenta pipeline com OpenTelemetry e precisa investigar job lento ou padrão de retry: a Buildkite cita o caso do Pinterest, que usou Honeycomb junto com a Buildkite para separar tempo de espera do agente do tempo de execução do script e identificar jobs por trás de picos no tempo de build.

Agent v3 tem prazo para sair de cena

O Elastic CI Stack v7, lançado junto com essas mudanças, traz o Agent v4 para instâncias Linux e Windows na AWS, remove o suporte ao Agent v3 e aposenta ou substitui alguns parâmetros de tracing e cancelamento. A Buildkite recomenda revisar arquivos de parâmetro customizados, automação de deploy e valores passados via AgentEnvFileUrl antes de atualizar. O suporte a todas as versões do Agent v3 termina em 3 de setembro de 2027, o que dá quase um ano para quem roda Elastic CI Stack na AWS planejar a migração sem pressa.

Fonte: InfoQ