Примечание: Администратор сайта должен включить code scanning для экземпляр GitHub Enterprise Server, прежде чем вы сможете использовать эту функцию. Если вы хотите использовать GitHub Actions для сканирования кода, администратор сайта также должен включить GitHub Actions и настроить необходимую инфраструктуру. Дополнительные сведения см. в разделе Настройка сканирования кода на устройстве.
Сведения о Рабочий процесс анализа CodeQL и скомпилированных языках
Настройте GitHub, чтобы использовать code scanning для своего репозитория, добавив в репозиторий рабочий процесс GitHub Actions. Для CodeQL code scanning добавьте Рабочий процесс анализа CodeQL. Дополнительные сведения см. в разделе Настройка проверки кода для репозитория.
Как правило, изменять созданный файл рабочего процесса для code scanning не требуется. Однако при необходимости можно настроить некоторые параметры рабочего процесса. Например, можно изменить GitHub Рабочий процесс анализа CodeQL, чтобы указать частоту сканирования, языки или каталоги для сканирования, а также то, что CodeQL code scanning ищет в коде. Если для компиляции кода используется определенный набор команд, может потребоваться изменить Рабочий процесс анализа CodeQL. Общие сведения о настройке code scanning и изменении файлов рабочего процесса см. в разделах Настройка сканирования кода и Изучение GitHub Actions.
Сведения об автоматической сборке для CodeQL
Code scanning выполняет запросы к одной или нескольким базам данных. Каждая база данных содержит представление всего кода на одном языке в репозитории.
Для скомпилированных языков C/C++, C#, и Java процесс заполнения этой базы данных включает сборку кода и извлечение данных. Для этих языков CodeQL анализирует созданные исходные файлы в репозитории. Для любого из этих языков можно отключить autobuild
и вместо этого использовать пользовательские команды сборки, чтобы анализировать только файлы, созданные с помощью этих пользовательских команд.
Для поддерживаемых скомпилированных языков можно использовать autobuild
действие в Рабочий процесс анализа CodeQL для сборки кода. Это позволяет избежать необходимости указывать явные команды сборки для C/C++, C#, и Java.
Если рабочий процесс использует таблицу language
, autobuild
пытается собрать каждый из компилируемых языков, перечисленных в матрице. Если вы не используете таблицу, autobuild
попытается выполнить сборку на поддерживаемом компилируемом языке с наибольшим числом исходных файлов в репозитории. За исключением Go, анализ других компилируемых языков в репозитории завершится ошибкой, если вы не предоставите команды сборки в явном виде.
Примечание. Если для GitHub Actions используются локальные средства выполнения тестов, может потребоваться установить дополнительное программное обеспечение для использования процесса autobuild
. Кроме того, что если для вашего репозитория требуется определенная версия инструмента сборки, вам может потребоваться сначала установить его вручную. Дополнительные сведения см. в разделе О средствах выполнения, размещенных в GitHub.
C/C++
Поддерживаемый тип системы | Имя системы |
---|---|
Операционная система | Windows, macOS и Linux |
Система сборки | Windows: MSbuild и скрипты сборки Linux и macOS: Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild и скрипты сборки |
Поведение шага autobuild
зависит от операционной системы, в которой выполняется извлечение. В Windows шаг autobuild
пытается выполнить автоматическое определение подходящего метода сборки для C/C++ с помощью следующего подхода:
- Вызов
MSBuild.exe
для файла решения (.sln
) или проекта (.vcxproj
), ближайшего к корневому каталогу. Еслиautobuild
обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них. - Вызов скрипта, который похож на скрипт сборки — build.bat, build.cmd и build.exe (в этом порядке).
На Linux и macOS шаг autobuild
проверяет наличие файлов в репозитории, чтобы определить используемую систему сборки:
- Поиск системы сборки в корневом каталоге.
- Если она не будет найдена, выполняется поиск по подкаталогам уникального каталога с системой сборки для C/C++.
- Выполнение соответствующей команду, чтобы настроить систему.
C#
Поддерживаемый тип системы | Имя системы |
---|---|
Операционная система | Windows и Linux |
Система сборки | .NET и MSbuild, а также скрипты сборки |
Процесс autobuild
пытается выполнить автоматическое определение подходящего метода сборки для C# с помощью следующего подхода:
- Вызов
dotnet build
для файла решения (.sln
) или проекта (.csproj
), ближайшего к корневому каталогу. - Вызов
MSbuild
(Linux) или (Windows) для файла решения (MSBuild.exe
) или проекта, ближайшего к корневому каталогу. Еслиautobuild
обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них. - Вызов скрипта, который выглядит как скрипт сборки —build и build.sh (в этом порядке для Linux) или build.bat, build.cmd и build.exe (в этом порядке для Windows).
Java
Поддерживаемый тип системы | Имя системы |
---|---|
Операционная система | Windows, macOS и Linux (без ограничений) |
Система сборки | Gradle, Maven и Ant |
Процесс autobuild
пытается определить систему сборки для баз кода Java, применяя следующую стратегию:
- Поиск файла сборки в корневом каталоге. Проверка наличия файлов сборки Gradle, затем Maven, а затем Ant.
- Запуск первого найденного файла сборки. Если присутствуют файлы и Gradle, и Maven, используется файл Gradle.
- В противном случае выполняется поиск файлов сборки в непосредственных подкаталогах корневого каталога. Если только один подкаталог содержит файлы сборки, запускается первый файл, определенный в этом подкаталоге (используя тот же приоритет, что и для 1). Если несколько подкаталогов содержат файлы сборки, возникает об ошибка.
Добавление шагов сборки для компилируемого языка
Если autobuild
не удается или вы хотите проанализировать другой набор исходных файлов, отличный от созданных процессом autobuild
, необходимо удалить autobuild
шаг из рабочего процесса и вручную добавить шаги сборки. Для C/C++, C#, Go, и проектов Java, CodeQL будут анализировать любой исходный код, созданный указанными шагами сборки. Сведения об изменении файла рабочего процесса см. в разделе Настройка сканирования кода.
После удаления шага autobuild
раскомментируйте запуска run
и добавьте команды сборки, которые подходят для вашего репозитория. Шаг рабочего процесса run
используется для запуска программы командной строки с помощью оболочки операционной системы. Вы можете изменить эти команды и добавить дополнительные команды для настройки процесса сборки.
- run: |
make bootstrap
make release
Дополнительные сведения о ключевое слово см. в run
разделе Синтаксис рабочего процесса для GitHub Actions.
Если репозиторий содержит несколько компилируемых языков, можно указать команды сборки для конкретного языка. Например, если репозиторий содержит C/C++, C# и Java и autobuild
правильно собирает C/C++ и C#, но сборка Java завершается сбоем, можно использовать в рабочем процессе приведенную ниже конфигурацию после шага init
. В ней указываются шаги сборки для Java, а для C/C++ и C# по-прежнему используется autobuild
:
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
name: Autobuild
uses: github/codeql-action/autobuild@v2
- if: matrix.language == 'java'
name: Build Java
run: |
make bootstrap
make release
Дополнительные сведения об условном параметре см. в if
разделе Синтаксис рабочего процесса для GitHub Actions.
Дополнительные советы и рекомендации по autobuild
созданию кода см. в разделе Устранение неполадок рабочего процесса CodeQL.
Если вы добавили шаги сборки вручную для скомпилированных языков, а code scanning по-прежнему не работают в репозитории, обратитесь в администратор сайта.