Fim do pacote multiplataforma do CodeQL: confira OS e CPU antes da versão
A versão de um scanner pode ser atualizada enquanto o nome do instalador permanece igual por anos. Se você baixa CodeQL por CI própria ou um espelho interno, confira tanto a versão quanto o arquivo de destino.
Em 22 de setembro de 2026, o GitHub anunciou a descontinuação do pacote CodeQL que reúne todas as plataformas. Este texto explica o anúncio e propõe uma migração verificável para pacotes específicos.
Descontinuação não é indisponibilidade imediata
A partir do CodeQL CLI 2.27.0, codeql-bundle.tar.gz e codeql-bundle.tar.zst estão depreciados, com remoção prevista para meados de março de 2027. A alternativa é o pacote correspondente ao sistema e à arquitetura suportados.
Binários Linux ARM64 existem apenas nos downloads específicos. Isso não significa que todos os workflows falham hoje. Primeiro descubra se a sua instalação baixa diretamente os arquivos afetados.
Encontre as instalações diretas
Pesquisar somente o YAML pode deixar passar imagens de contêiner, scripts de inicialização e repositórios internos. Ligue a construção da URL de download ao ambiente que efetivamente executa a análise.
Registre ambiente, OS, CPU, arquivo, cache e responsável. É uma sugestão operacional, não uma exigência oficial. Não publique tokens secretos nem endereços internos em issues públicas.
O nome do sistema não basta
Linux x86-64 e ARM64 são alvos diferentes. Distinga host e contêiner e use os nomes exatos dos arquivos da release. Rejeite combinações desconhecidas em vez de escolher silenciosamente um padrão.
A release 2.27.0 lista CLI e pacotes Linux ARM64. A existência do download não garante todas as linguagens e configurações de build. Os requisitos atuais classificam Linux ARM64 como beta; confira as condições relevantes.
Não deixe o cache esconder o problema
Trocar o nome do arquivo não testa o caminho novo se um cache entrega o executável antigo. Inclua plataforma e versão nas chaves e caminhos do espelho; registre o arquivo e a versão realmente usados na primeira validação.
Use distribuições oficiais e informações de integridade disponíveis. Ao conservar artefatos verificados internamente, registre também a versão e a plataforma originais. Observe especialmente caches compartilhados entre arquiteturas.
Valide a análise inteira
Iniciar o CLI não comprova equivalência com a configuração anterior. No mesmo commit de um repositório representativo, confira criação do banco, consultas, envio de resultados, linguagens e modos de build.
Misturar migração, refatoração e mudança de política dificulta explicar diferenças. Revise a instalação separadamente e investigue resultados inesperados com versões da ferramenta, dos packs e logs de build.
Comece por um caminho reproduzível
Uma equipe pequena pode começar pela CI própria mais importante. Documente critérios de sucesso e configurações de reversão; compartilhe o mesmo padrão com responsáveis por espelhos e imagens antigas.
Releases e issues públicas ajudam a investigar compatibilidade, mas resultados de outro repositório não validam o seu ambiente. Este artigo não afirma consenso da comunidade nem taxas de sucesso.
O registro de mudança de hoje
Inclua no PR o arquivo antigo, o novo mapeamento, o ambiente real e os resultados representativos. Liste também os ambientes ainda não testados para deixar claro o alcance concluído.
Antes da remoção, é preciso mudar e validar a instalação, não apenas ocultar o aviso. Defina quem acompanhará o changelog e os requisitos caso uma data mais precisa seja anunciada.