Настройка рабочего процесса CodeQL для скомпилированных языков

Сведения о Рабочий процесс анализа CodeQL и скомпилированных языках

Для CodeQL code scanning можно использовать настройку по умолчанию, которая анализирует код и автоматически настраивает code scanning, или расширенную настройку, которая создает файл рабочего процесса, который можно изменить. В настоящее время настройка по умолчанию не поддерживает скомпилированные языки, поэтому необходимо использовать расширенную настройку. Дополнительные сведения см. в разделе Настройка проверки кода для репозитория.

Как правило, изменять созданный файл рабочего процесса для code scanning не требуется. Однако при необходимости можно настроить некоторые параметры рабочего процесса. Например, можно изменить GitHub Рабочий процесс анализа CodeQL, чтобы указать частоту сканирования, языки или каталоги для сканирования, а также то, что CodeQL code scanning ищет в коде. Если для компиляции кода используется определенный набор команд, может потребоваться изменить Рабочий процесс анализа CodeQL. Общие сведения о настройке code scanning и изменении файлов рабочего процесса см. в разделах Настройка сканирования кода и Изучение GitHub Actions.

Сведения об автоматической сборке для CodeQL

Code scanning выполняет запросы к одной или нескольким базам данных. Каждая база данных содержит представление всего кода на одном языке в репозитории. Для скомпилированных языков C/C++, C#, Go, Kotlin, и Java процесс заполнения этой базы данных включает сборку кода и извлечение данных. Для этих языков CodeQL анализирует созданные исходные файлы в репозитории. Для любого из этих языков можно отключить autobuild и вместо этого использовать пользовательские команды сборки, чтобы анализировать только файлы, созданные с помощью этих пользовательских команд.

Для поддерживаемых скомпилированных языков можно использовать autobuild действие в Рабочий процесс анализа CodeQL для сборки кода. Это позволяет избежать необходимости указывать явные команды сборки для C/C++, C#, Go, Kotlin, и Java.

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

C/C++

Поддерживаемый тип системы	Имя системы
Операционная система	Windows, macOS и Linux
Система сборки	Windows: MSbuild и скрипты сборки Linux и macOS: Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild и скрипты сборки

Поведение шага autobuild зависит от операционной системы, в которой выполняется извлечение. В Windows шаг autobuild пытается выполнить автоматическое определение подходящего метода сборки для C/C++ с помощью следующего подхода:

1. Вызов MSBuild.exe для файла решения (.sln) или проекта (.vcxproj), ближайшего к корневому каталогу. Если autobuild обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них.
2. Вызов скрипта, который похож на скрипт сборки — build.bat, build.cmd и build.exe (в этом порядке).

На Linux и macOS шаг autobuild проверяет наличие файлов в репозитории, чтобы определить используемую систему сборки:

1. Поиск системы сборки в корневом каталоге.
2. Если она не будет найдена, выполняется поиск по подкаталогам уникального каталога с системой сборки для C/C++.
3. Выполнение соответствующей команду, чтобы настроить систему.

C#

Поддерживаемый тип системы	Имя системы
Операционная система	Windows и Linux
Система сборки	.NET и MSbuild, а также скрипты сборки

Процесс autobuild пытается выполнить автоматическое определение подходящего метода сборки для C# с помощью следующего подхода:

1. Вызов dotnet build для файла решения (.sln) или проекта (.csproj), ближайшего к корневому каталогу.
2. Вызов MSbuild (Linux) или (Windows) для файла решения (MSBuild.exe) или проекта, ближайшего к корневому каталогу. Если autobuild обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них.
3. Вызов скрипта, который выглядит как скрипт сборки —build и build.sh (в этом порядке для Linux) или build.bat, build.cmd и build.exe (в этом порядке для Windows).

Go

Поддерживаемый тип системы	Имя системы
Операционная система	Windows, macOS и Linux
Система сборки	Модули dep Go и Glide, а также скрипты сборки, включая makefiles и скрипты Ninja

Процесс autobuild пытается автоматически определить подходящий способ установки зависимостей, необходимых репозиторию Go, перед извлечением всех .go файлов:

1. Вызовите make, ninja``./build или ./build.sh (в таком порядке), пока не будет выполнена одна из этих команд, а следующая go list ./... команда также не будет успешно выполнена, указывая на установку необходимых зависимостей.
2. Если ни одна из этих команд не выполнена успешно, найдите go.modили glide.yaml``Gopkg.toml и выполните команду go get (если не используется поставщик) dep ensure -v илиglide install, соответственно, чтобы попытаться установить зависимости.
3. Наконец, если файлы конфигураций для этих диспетчеров зависимостей не найдены, измените порядок структуры каталогов репозитория, подходящую для добавления в GOPATH, и используйте для go get установки зависимостей. После завершения извлечения структура каталогов возвращается в нормальное состояние.
4. Извлеките весь код Go в репозитории, аналогично выполнению go build ./....

Java и Kotlin

Поддерживаемый тип системы	Имя системы
Операционная система	Windows, macOS и Linux (без ограничений)
Система сборки	Gradle, Maven и Ant

Процесс autobuild пытается определить систему сборки для баз кода Java, применяя следующую стратегию:

1. Поиск файла сборки в корневом каталоге. Проверка наличия файлов сборки Gradle, затем Maven, а затем Ant.
2. Запуск первого найденного файла сборки. Если присутствуют файлы и Gradle, и Maven, используется файл Gradle.
3. В противном случае выполняется поиск файлов сборки в непосредственных подкаталогах корневого каталога. Если только один подкаталог содержит файлы сборки, запускается первый файл, определенный в этом подкаталоге (используя тот же приоритет, что и для 1). Если несколько подкаталогов содержат файлы сборки, возникает об ошибка.

Добавление шагов сборки для компилируемого языка

Если autobuild не удается или вы хотите проанализировать набор исходных файлов, отличный от созданных процессом autobuild , необходимо удалить autobuild этот шаг из рабочего процесса и вручную добавить шаги сборки. Для проектов C/C++, C#, Go, Kotlin, и 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 по-прежнему не работают в репозитории, обратитесь в Поддержка GitHub.