Fine del bundle CodeQL multipiattaforma: controllare OS e CPU prima della versione
La versione di uno scanner di sicurezza può cambiare mentre il nome dell’installer rimane identico per anni. Chi scarica CodeQL tramite CI personalizzata o mirror interno dovrebbe controllare insieme versione e file.
Il 22 settembre 2026 GitHub ha annunciato la dismissione del bundle CodeQL per tutte le piattaforme. Qui distinguiamo l’annuncio dai suggerimenti per una migrazione verificabile ai pacchetti specifici.
Dismissione non significa guasto immediato
Da CodeQL CLI 2.27.0, codeql-bundle.tar.gz e codeql-bundle.tar.zst sono deprecati; la rimozione è prevista a metà marzo 2027. L’alternativa è il bundle per sistema operativo e architettura supportati.
I binari Linux ARM64 sono solo nei download specifici, non nel bundle complessivo. Non significa che ogni workflow fallisca oggi: controllate prima se scaricate direttamente quei file.
Individuare le installazioni dirette
Una ricerca limitata al YAML può ignorare immagini di container, script di bootstrap e archivi interni. Collegate la costruzione dell’URL all’ambiente che esegue davvero l’analisi.
Annotate ambiente, OS, CPU, file, cache e responsabile. È un suggerimento operativo, non un requisito ufficiale. Non pubblicate token segreti o indirizzi interni nelle issue.
Il nome del sistema non basta
Linux x86-64 e ARM64 sono destinazioni diverse. Distinguete host e container e usate i nomi esatti degli asset di rilascio. Rifiutate combinazioni sconosciute invece di scegliere un default silenzioso.
La release 2.27.0 elenca CLI e bundle Linux ARM64. Un download disponibile non garantisce ogni linguaggio e configurazione di build. I requisiti attuali indicano supporto beta per Linux ARM64: verificate le condizioni applicabili.
La cache non deve nascondere il problema
Cambiare il file non verifica il nuovo percorso se una cache fornisce ancora il vecchio eseguibile. Inserite piattaforma e versione nelle chiavi e nei percorsi del mirror; registrate file e versione effettivamente usati nella prima prova.
Usate distribuzioni ufficiali e informazioni di integrità disponibili. Per gli asset verificati conservati internamente, annotate anche versione e piattaforma originali. Controllate soprattutto le cache condivise fra architetture.
Verificare l’intera analisi
L’avvio del CLI non dimostra equivalenza con la configurazione precedente. Sullo stesso commit di un repository rappresentativo controllate creazione del database, query, caricamento dei risultati, linguaggi e modalità di build.
Mescolare migrazione, refactoring e modifica delle politiche rende difficile spiegare le differenze. Esaminate l’installazione separatamente e indagate con versioni di tool e pack e log di build.
Una prima strada riproducibile
Un piccolo team può partire dalla CI personalizzata più importante. Documentate criteri di successo e impostazioni di rollback, poi condividete lo stesso metodo con i responsabili di mirror e immagini datate.
Release e issue pubbliche sono utili per la compatibilità, ma i risultati altrui non validano il vostro ambiente. Qui non si affermano consenso della comunità o tassi di successo.
Cosa registrare nel PR
Allegate vecchio file, nuova mappatura, ambiente reale e risultati rappresentativi. Indicate anche ciò che non avete ancora testato per rendere chiaro il perimetro completato.
Prima della rimozione bisogna modificare e verificare il percorso, non soltanto nascondere un avviso. Assegnate a qualcuno il controllo delle comunicazioni e dei requisiti, anche per un’eventuale data più precisa.