Что делать, если CodeQL не сканирует с Xcode 27? Руководство по исправлению 2026

GitHub подтвердил ограничения CodeQL для Xcode 27 и Swift 6.4 в объявлении от 19 октября 2026 года. Если вы сканируете Swift, закрепите поддерживаемую комбинацию macOS 26 или более ранней версии и Xcode 26 или более ранней версии, а переход на Swift 6.4 отложите. Для C/C++, C# и Java оцените build mode none, но проверьте полноту анализа: успешный запуск workflow сам по себе не доказывает, что CodeQL полностью обработал код.

Кому пригодится: руководителям IT и платформенным инженерам, отвечающим за GitHub Actions и рабочие процессы CodeQL.
Специалистам по безопасности Swift- и iOS-проектов, которым нужно оценить влияние Swift 6.4 и Xcode 27.
Техническим руководителям, планирующим Mac-узлы, версии инструментов и восстановление сканирования.

Последнее обновление: 24 октября 2026 года. Данные сверены с объявлением GitHub о CodeQL, macOS 27, Xcode 27 и Swift 6.4 и текущей документацией GitHub по компилируемым языкам и режимам сборки CodeQL.

Где проходит граница: язык, Xcode, macOS или режим сборки?

После обновления среды ошибки сканирования легко приписать одной причине — например, новому Xcode. Однако для диагностики нужно разделить ограничения Swift 6.4, отслеживания сборки при установленном Xcode 27, операционной системы runner и выбранного режима CodeQL. Это разные условия, поэтому решение для одного набора репозиториев может оказаться неверным для другого.

В частности, успешная компиляция приложения подтверждает, что сработал компилятор, но не означает, что CodeQL создал полную базу для анализа. А успешный статус workflow не доказывает, что база охватила нужные исходники, зависимости и сгенерированный код.

Почему нельзя решить проблему заменой Mac-узла? Ограничение поддержки Swift 6.4 относится к возможностям CodeQL, а не только к конкретной машине. Перенос той же конфигурации на другой Mac не добавляет CodeQL поддержку языка. Сначала зафиксируйте версии и режим анализа, затем проверяйте сам runner.

Какие языки затрагивает Xcode 27? Согласно объявлению GitHub, при установленном Xcode 27 недоступно отслеживаемое извлечение для C/C++, C#, Go, Java, Kotlin и Swift. Это точный перечень языков из объявления; его не следует расширять на все языки и все способы анализа. GitHub также указывает, что соответствующее извлечение на macOS 27 может быть недоступно, но формулировка «может быть» не означает неизбежного отказа каждого проекта на этой ОС.

Условия сканирования Что подтверждено Первое действие
Swift 6.4 CodeQL не поддерживает анализ Swift 6.4, согласно объявлению GitHub от 19 октября 2026 года Приостановить переход Swift либо вернуть поддерживаемую версию
Xcode 27 и отслеживаемая сборка Для C/C++, C#, Go, Java, Kotlin и Swift недоступно отслеживаемое извлечение Проверить фактический Xcode и применить поддерживаемую комбинацию
macOS 27 Извлечение может быть недоступно; GitHub не утверждает, что любой проект обязательно завершится ошибкой Проверить образ runner, выбранный Xcode и режим сборки
C/C++, C# или Java без отслеживания сборки Можно рассмотреть build mode none, но он не является автоматически эквивалентным отслеживаемой сборке Провести сравнительную проверку покрытия и базы

Сценарий Swift: как вернуть анализ без ложного «зелёного» результата?

Для Swift вывод прямой: не пытайтесь исправить отсутствие поддержки Swift 6.4 сменой Mac-узла или повторным запуском того же workflow. Временно закрепите версию Swift, поддерживаемую выбранной версией CodeQL, и задайте для сканирования macOS 26 или более раннюю версию вместе с Xcode 26 или более ранней версией. Именно такое направление для Swift-сканирования указывает GitHub в объявлении о совместимости.

Можно ли оставить Swift 6.4, если приложение успешно компилируется? Успешная компиляция не отменяет подтверждённого ограничения CodeQL. Если проверка безопасности должна охватывать Swift-код, не считайте задачу выполненной, пока не восстановлен поддерживаемый путь анализа и не проверены результаты CodeQL.

Разведите обновление приложения и обновление среды сканирования. Если продуктовая команда уже переходит на Swift 6.4, а безопасность не может отложить анализ, временно отделите сканирующий workflow от основного сборочного окружения. Это не гарантирует, что код приложения целиком совместим со старым инструментарием: совместимость нужно проверить на конкретном репозитории. Но такой эксперимент позволит установить, устраняет ли возврат поддерживаемых версий именно проблему сканирования.

При фиксации версии проверьте, что runner действительно использует выбранный Xcode. В конфигурации workflow могут быть указаны одна версия образа и другая команда выбора Xcode; также образ может обновиться независимо от намерений команды. Сверяйте журнал задания с настройками и фактическими путями к инструментам. За подробной процедурой приёмки закреплённой среды можно обратиться к материалу о поиске оставшихся workflow на macOS 14 Runner: используйте его как пример инвентаризации зависимостей, а не как подтверждение совместимости Xcode 27.

Сценарий отслеживаемой сборки: что делать с Xcode 27 и macOS 27?

Если задача анализирует компилируемый код через отслеживание сборки, начните с фактической среды запуска, а не с текста ошибки. Уточните образ runner, версию macOS, установленный и выбранный Xcode, язык задания и указанный режим CodeQL. Затем сравните результаты на закреплённом поддерживаемом образе и на текущем — так вы не перепутаете влияние операционной системы с влиянием Xcode или языковой версии.

Xcode 27 и macOS 27 — связанные, но не взаимозаменяемые границы совместимости. Установка Xcode 27 связана с недоступностью отслеживаемого извлечения для перечисленных GitHub языков. Для macOS 27 GitHub говорит о возможной недоступности соответствующего извлечения. Поэтому не следует утверждать, что все проекты на macOS 27 обязательно не сканируются, или что отказ на одном runner доказывает общую несовместимость всей операционной системы.

Как закрепить macOS и Xcode для CodeQL? Зафиксируйте поддерживаемый образ runner и выбор Xcode в workflow; затем проверьте версии в журнале конкретного запуска. Нельзя считать настройку достаточной, если она задаёт лишь желаемый номер версии, но не подтверждает фактически запущенный инструмент. Дальше выполните сканирование в отдельном запуске, изучите создание базы и результаты анализа, а затем сравните их с текущей конфигурацией.

Практический порядок восстановления:

  1. Найдите все workflow, где запускается CodeQL, и сопоставьте их с репозиториями и языками.
  2. Для каждого задания зафиксируйте фактические версии runner, macOS, Xcode, Swift и используемый CodeQL build mode.
  3. Разделите задачи на Swift-сканирование, отслеживаемую сборку и анализ без отслеживания сборки.
  4. Для Swift и зависимых от отслеживания задач подготовьте вариант с macOS 26 или более ранней версией и Xcode 26 или более ранней версией, если это подходит конкретному проекту.
  5. Для одной репрезентативной ветки запустите проверку на закреплённой среде, не меняя одновременно несколько независимых параметров.
  6. Убедитесь, что база CodeQL создана и содержит ожидаемый проектный код; проверьте завершение анализа и публикацию результатов.
  7. Зафиксируйте разницу между прежним и восстановленным результатом, назначьте владельца обновления и не возвращайте новую среду в обязательный путь до прохождения приёмки.

Для проверки именно публикации не ограничивайтесь логом анализатора: сверяйте состояние загрузки SARIF и результат в целевой системе. В документации GitHub по загрузке файла SARIF описаны условия передачи результатов. Это отдельный участок цепочки: база и анализ могут завершиться, но сигнал безопасности не появится там, где его ожидают, если публикация не состоялась.

В конфигурациях с Xcode 27 полезно просмотреть и примечания к образу runner с Xcode 27. Наличие образа в инфраструктуре не означает, что он подходит для каждой задачи CodeQL. Допуск образа должен зависеть от конкретного языка и режима сборки.

Когда build mode none допустим вместо отслеживания?

GitHub предлагает рассматривать build mode none для C/C++, C# и Java. Это не универсальный обход ограничения Xcode 27 и не автоматическая замена отслеживаемого извлечения для всех репозиториев. Перед изменением режима выясните, что именно CodeQL сможет получить без перехвата сборки, и подтвердите, что такой результат приемлем для требований безопасности вашего проекта. Сведения о режимах и языках приведены в документации CodeQL по компилируемым языкам и в описании параметров сборки.

Проверьте как минимум состав исходников, доступность информации о зависимостях, включение сгенерированного кода и содержимое базы. Затем сравните полученные результаты с последним анализом, которому команда доверяет. Исчезновение ошибки запуска не является доказательством равного покрытия: важны те файлы и свойства проекта, которые должны анализироваться в вашем процессе.

Когда none не подходит? Если проект критически зависит от генерации кода, сложных параметров сборки или состава исходников, который определяется во время компиляции, решение принимайте только после проверки базы и набора результатов. Для отдельных проектов отличия могут быть допустимы; переносить этот вывод на другие репозитории нельзя.

Если в результатах присутствуют предупреждения по сгенерированным файлам, отделяйте проблему покрытия от политики выдачи предупреждений. В документации GitHub об оповещениях в сгенерированном коде описано, как такие сигналы трактуются. Не исключайте каталоги генерации только ради чистого отчёта: сначала выясните, не удалит ли правило исключения код, который должен проверяться.

Вариант Для каких задач рассматривать Что проверить до принятия
Отслеживаемая сборка на закреплённой среде Swift и задачи, которым нужен именно путь с отслеживанием сборки Совместимость версий, создание базы, состав включённых файлов и публикацию результатов
build mode none C/C++, C# и Java в пределах рекомендаций GitHub Исходники, зависимости, генерацию, содержимое базы и отличие результатов от принятого базового сканирования
Сохранение текущей среды без проверки Не является вариантом восстановления для обязательного контроля Сам по себе успешный статус задания не подтверждает завершённость анализа

Отдельная инвентаризация Intel Mac

Поддержка CodeQL для Intel Mac — отдельный пункт планирования: GitHub сообщил, что её планируется вывести из эксплуатации в середине декабря 2026 года. Срок и статус следует сверять с официальным объявлением GitHub, поскольку это календарное изменение поддержки, а не способ исправить ограничение Xcode 27.

Запишите, какие задачи CodeQL ещё используют Intel Mac, какой команде принадлежит каждый runner и кто отвечает за перенос. Затем проверьте целевую архитектуру, инструменты и зависимости отдельно для каждого workflow. Не меняйте runner только потому, что наступает срок вывода из эксплуатации: сначала убедитесь, что альтернативная среда проходит проверки сканирования, сборки и публикации результатов.

Выбор пути восстановления для каждого workflow

Соберите решение по рабочей нагрузке: один репозиторий может содержать Swift и C++, а значит, одна настройка не обязательно подходит для всех языковых задач. Отдельно запишите, где нужен Mac, а где ограничение связано не с Mac как таковым, а с поддержкой языка или способом извлечения.

Тип задачи Предпочтительный путь проверки Критерий допуска
Swift, включая проект на Swift 6.4 Временно закрепить поддерживаемую версию Swift и сочетание macOS 26 или более ранней версии с Xcode 26 или более ранней версией CodeQL создаёт ожидаемую базу, анализирует требуемый код, а результат публикуется
C/C++, C# или Java с проблемой отслеживания Отдельно оценить build mode none или закреплённую среду для отслеживания Покрытие и база проверены на конкретном репозитории; режим не выбран только ради зелёного workflow
Go или Kotlin при Xcode 27 Проверить язык и путь извлечения по объявлению GitHub; не переносить рекомендацию none без подтверждения Запуск проверен с учётом фактического runner и режима, а данные анализа присутствуют
Runner на macOS 27 Проверить версию ОС, Xcode и build mode по отдельности Результат воспроизводится на конкретной конфигурации; возможное ограничение не выдано за общий отказ

Перед закрытием инцидента отметьте в карточке workflow:

  • [ ] Язык и репозиторий сопоставлены с подтверждёнными ограничениями CodeQL.
  • [ ] Фактические macOS, Xcode и Swift сверены с конфигурацией runner.
  • [ ] Build mode записан явно, а его выбор объяснён требованиями проекта.
  • [ ] База CodeQL содержит ожидаемые исходники и нужные проекту сведения.
  • [ ] Сгенерированный код и зависимости проверены, а исключения каталогов обоснованы.
  • [ ] Анализ завершился, результаты опубликованы и доступны в нужном месте.
  • [ ] Владелец workflow и план обновления среды назначены.
  • [ ] Задачи на Intel Mac внесены в отдельный план миграции.

Для распределения задач между собственными узлами и другими средами учитывайте реальную потребность каждого workflow в macOS, а не только привычную конфигурацию команды. Если вы пересматриваете саму схему размещения, сопоставьте эту проверку с материалом о вариантах использования Mac для рабочих нагрузок. Он не заменяет техническую приёмку CodeQL; это отдельная оценка того, где конкретному процессу действительно требуется Mac.

Решение о Mac-узле имеет смысл принимать только после выяснения, что анализ действительно требует Mac и существующая среда не удовлетворяет этому требованию. Собственный Mac может быть уместен, если команда постоянно выполняет предсказуемую нагрузку и готова отвечать за оборудование, обновления и эксплуатацию. Удалённая аренда Mac может быть удобна для временного размещения или проверки альтернативного узла, но не устраняет несовместимость Swift 6.4 и не гарантирует поддержку конкретного сочетания Xcode и CodeQL. Не переносите сканирование до проверки образа, доступа, инструментов и результатов на целевой среде.

Если после инвентаризации вы подтвердили, что для части сканирования нужен Mac, а текущий пул не подходит, сравните собственное оборудование с условиями удалённой аренды, не подменяя совместимость обещаниями поставщика. Для предварительной оценки доступны условия и цены KVMFLUX; до выбора проверьте, подходят ли предлагаемые условия именно вашим требованиям к среде и эксплуатации. Сначала закрепите версии, режим сборки и критерии полноты анализа — и только затем решайте, нужно ли менять способ размещения Mac-задачи.

Читайте также

Проверьте сборку CodeQL на выделенном Mac

Арендуйте выделенный Mac mini M4 в KVMFLUX, чтобы проверять сценарии сборки Swift в контролируемой среде macOS. Подключайтесь по SSH для настройки узла CI и запуска команд сборки или используйте VNC, когда нужен графический интерфейс Xcode. Вы сами решаете, когда обновлять macOS и Xcode, и можете повторно проверять конвейер в привычной конфигурации. Выберите аренду на сутки, неделю, месяц или квартал — для разовой диагностики или постоянного узла сборки.

Mac Mini M4 · 16GB / 256GB
Сутки$19.3 /сутки
Неделя$52.2 /нед.
Месяц$96.7 /мес.
Квартал$263 /квартал