Fin du bundle CodeQL multiplateforme : vérifier les chemins OS et CPU avant la version
La version d’un outil de sécurité peut évoluer alors que le nom du fichier d’installation reste inchangé. Si CodeQL arrive par une CI maison ou un miroir interne, vérifiez la version et le fichier téléchargé ensemble.
GitHub a annoncé le 22 septembre 2026 la dépréciation du bundle CodeQL réunissant toutes les plateformes. Cet article distingue les faits annoncés des conseils pour rendre la migration vérifiable.
Une dépréciation, pas une panne immédiate
Depuis CodeQL CLI 2.27.0, codeql-bundle.tar.gz et codeql-bundle.tar.zst sont dépréciés. Leur retrait est prévu mi-mars 2027 ; utilisez le bundle correspondant au système et à l’architecture pris en charge.
Les binaires Linux ARM64 existent uniquement dans les téléchargements spécifiques. Cela ne signifie pas que tous les workflows échouent dès maintenant. Vérifiez d’abord si votre installation utilise les fichiers concernés.
Retrouver les installations directes
Chercher seulement dans le YAML peut manquer les images de conteneur, scripts d’amorçage et dépôts internes. Reliez le code construisant l’URL à l’environnement exécutant réellement l’analyse.
Notez environnement, OS, CPU, fichier, emplacement du cache et responsable. C’est une proposition d’exploitation, pas une obligation officielle. Ne publiez ni jetons secrets ni adresses internes dans une issue publique.
Le nom de l’OS ne suffit pas
Linux x86-64 et ARM64 sont deux cibles différentes. Distinguez hôte et conteneur et reprenez les noms exacts des fichiers de release. Rejetez les combinaisons inconnues plutôt que de choisir silencieusement une valeur par défaut.
La release 2.27.0 présente un CLI et un bundle Linux ARM64. Une archive disponible ne garantit pas toutes les combinaisons de langages et de compilation. Les exigences actuelles qualifient Linux ARM64 de bêta : vérifiez les conditions utiles à votre projet.
Ne pas laisser le cache masquer le changement
Modifier le nom du téléchargement ne teste pas le nouveau chemin si le cache fournit toujours l’ancien exécutable. Faites apparaître plateforme et version dans les clés et chemins du miroir ; relevez le fichier et la version réellement utilisés.
Utilisez les distributions officielles et leurs informations d’intégrité. Pour un artefact vérifié conservé en interne, gardez aussi sa version et sa plateforme d’origine. Attention aux noms de cache partagés entre architectures.
Vérifier toute l’analyse
Le démarrage du CLI ne prouve pas l’équivalence. Sur le même commit d’un dépôt représentatif, vérifiez création de base, exécution des requêtes et envoi des résultats, ainsi que langages et modes de compilation.
Mélanger migration, refactorisation et changement de politique rend les écarts difficiles à expliquer. Examinez l’installation séparément et utilisez versions de l’outil, des packs et journaux de compilation pour enquêter.
Commencer par un chemin reproductible
Une petite équipe peut commencer par sa CI maison la plus importante. Notez critères de réussite et réglages de retour arrière, puis appliquez la même méthode aux responsables des miroirs et anciennes images.
Releases et issues publiques aident à explorer la compatibilité, mais les résultats d’un autre dépôt ne remplacent pas les vôtres. Aucun consensus communautaire ni taux de réussite n’est affirmé ici.
Que conserver dans le PR ?
Ajoutez ancien fichier, nouvelle correspondance des plateformes, environnement réel et résultats représentatifs. Précisez aussi les environnements non testés pour rendre le périmètre lisible.
Avant le retrait, il faut modifier et valider le chemin d’installation, pas seulement cacher l’avertissement. Désignez quelqu’un pour relire les annonces et exigences si une date plus précise est publiée.