Отказ от общего пакета CodeQL: сначала проверьте пути установки для ОС и CPU
Версию средства анализа обновляют, а имя установочного файла иногда годами остаётся прежним. Если CodeQL загружается через собственный CI или внутреннее зеркало, проверьте одновременно версию и выбранный архив.
22 сентября 2026 года GitHub объявил о прекращении поддержки общего пакета CodeQL для всех платформ. Ниже — содержание объявления и практические предложения по проверяемому переходу на отдельные пакеты.
Устаревание не равно сегодняшнему отказу
Начиная с CodeQL CLI 2.27.0, codeql-bundle.tar.gz и codeql-bundle.tar.zst считаются устаревшими. Удаление запланировано на середину марта 2027 года; рекомендуется пакет для поддерживаемой ОС и архитектуры.
Бинарные файлы Linux ARM64 доступны только в отдельных платформенных загрузках. Это не означает немедленный отказ всех существующих процессов. Сначала выясните, скачиваете ли вы затронутые архивы напрямую.
Найдите прямые установки
Поиск только в YAML пропустит образы контейнеров, загрузочные скрипты и внутренние хранилища артефактов. Свяжите место формирования URL с окружением, где реально выполняется анализ.
Запишите окружение, ОС, CPU, файл, кэш и ответственного. Это эксплуатационная рекомендация, не официальное требование. Не публикуйте секретные токены и внутренние адреса в открытых задачах.
Названия ОС недостаточно
Linux x86-64 и ARM64 требуют разных файлов. Различайте хост и контейнер, используйте точные имена ресурсов релиза. Неизвестную комбинацию лучше явно отклонить, чем незаметно выбрать вариант по умолчанию.
В релизе 2.27.0 перечислены CLI и пакеты Linux ARM64. Наличие загрузки не гарантирует поддержку любой комбинации языка и сборки. В текущих требованиях Linux ARM64 отмечен как beta: проверьте нужные условия.
Не позволяйте кэшу скрывать ошибку
Новое имя архива ничего не доказывает, если старый исполняемый файл приходит из кэша. Включайте платформу и версию в ключи и пути зеркала; при первой проверке фиксируйте реально использованные файл и версию CLI.
Используйте официальные дистрибутивы и сведения для проверки целостности. Внутренние копии проверенных артефактов сопровождайте исходной версией и платформой. Особенно проверьте кэши с одним именем для разных архитектур.
Проверяйте весь анализ
Успешный запуск CLI ещё не означает эквивалентность. На одном коммите представительного репозитория проверьте создание базы, выполнение запросов, загрузку результатов, охват языков и режимов сборки.
Не смешивайте переход с рефакторингом приложения или изменением политики запросов. Рассматривайте установку отдельно, а неожиданные различия исследуйте по версиям инструмента, пакетов и журналам сборки.
Начните с воспроизводимого пути
Небольшая команда может начать с самого важного собственного CI. Запишите критерии успеха и настройки отката, затем передайте те же критерии владельцам зеркал и старых образов.
Публичные релизы и задачи помогают исследовать совместимость, но чужие результаты не заменяют ваши. Здесь не заявляется ни консенсус сообщества, ни процент успешных миграций.
Что оставить в PR
Приложите прежнее имя файла, новое соответствие платформ, реальное окружение и результаты анализа. Укажите также непроверенные окружения, чтобы граница выполненной работы была понятна.
До удаления надо изменить и проверить путь установки, а не просто скрыть предупреждение. Назначьте ответственного за повторную проверку официальных изменений и возможного уточнения даты.