{"meta":{"title":"Опции и шаги сборки CodeQL для скомпилированных языков","intro":"Узнайте, как CodeQL строит скомпилированные языки, включая доступные режимы сборки и специфическое для языка поведение автосборки для C/C++, C#, Go, Java, Kotlin, Rust и Swift.","product":"Безопасность и качество кода","breadcrumbs":[{"href":"/ru/code-security","title":"Безопасность и качество кода"},{"href":"/ru/code-security/reference","title":"Reference"},{"href":"/ru/code-security/reference/code-scanning","title":"Проверка кода"},{"href":"/ru/code-security/reference/code-scanning/codeql","title":"CodeQL"},{"href":"/ru/code-security/reference/code-scanning/codeql/build-options-for-compiled-languages","title":"Варианты сборки для скомпилированных языков"}],"documentType":"article"},"body":"# Опции и шаги сборки CodeQL для скомпилированных языков\n\nУзнайте, как CodeQL строит скомпилированные языки, включая доступные режимы сборки и специфическое для языка поведение автосборки для C/C++, C#, Go, Java, Kotlin, Rust и Swift.\n\n## Шаги автостроки для скомпилированных языков\n\nGitHub-Размещённые бегущие всегда запускаются с программным обеспечением, требуемым .`autobuild` Если вы используете самостоятельные раннеры для GitHub Actions, возможно, потребуется установить дополнительное программное обеспечение для использования процесса `autobuild` . Кроме того, что если для вашего репозитория требуется определенная версия инструмента сборки, вам может потребоваться сначала установить его вручную.\n\n> \\[!NOTE]\n> Если рабочий процесс использует таблицу `language`, `autobuild` пытается собрать каждый из компилируемых языков, перечисленных в матрице. Если вы не используете таблицу, `autobuild` попытается выполнить сборку на поддерживаемом компилируемом языке с наибольшим числом исходных файлов в репозитории. За исключением Go, анализ других компилируемых языков в репозитории завершится ошибкой, если вы не предоставите команды сборки в явном виде.\n\n## Создание C/C++\n\nCodeQL поддерживает `none`режимы сборки , `autobuild` или `manual` для кода на C/C++.\n\nЕсли включить настройку по умолчанию для репозитория, содержащего код C/C++, режим сборки устанавливается `none` автоматически.\n\n### Нет сборки для C/C++\n\nCodeQL будет выводить компиляционные единицы C/C++ через расширения исходных файлов. Для каждого найденного исходного файла флаги компиляции и пути включения определяются путем проверки кодовой базы без необходимости использования рабочей команды сборки.\n\n#### Точность анализа без сборки для C/C++\n\nСоздание базы CodeQL данных на C/C++ без сборки может давать менее точные результаты, чем использование `autobuild` или ручные этапы сборки в некоторых случаях; например, если:\n\n* Код сильно зависит от пользовательских макросов/определений, недоступных в существующих заголовках\n* Кодовая база имеет множество внешних зависимостей\n\nВы можете обеспечить более точный анализ, выполнив следующие действия.\n\n* Размещение пользовательских макросов и определений в файлах заголовков, которые включены в соответствующие исходные файлы\n* Убедитесь, что внешние зависимости (заголовки) доступны в каталогах включения системы или в рабочей области\n* Запустите экстракцию на целевой платформе. Например, выберите Windows runner для анализа проектов Windows, чтобы получить доступ к специфичным для платформы заголовкам и компиляторам\n\n### Сводка по автостроке для C/C++\n\n| Поддерживаемый тип системы | Системное имя                                                                                                                             |\n| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |\n| Операционная система       | Windows, macOS и Linux                                                                                                                    |\n| Система сборки             | Windows: скрипты для сборки и сборки MS<br/>Linux и macOS: Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild и скрипты сборки |\n\nПоведение шага `autobuild` зависит от операционной системы, в которой выполняется извлечение.\n\n### Автоопределение Windows\n\nВ Windows шаг `autobuild` пытается автоматически определить подходящий метод сборки для C/C++ с помощью следующего подхода:\n\n1. Вызов `MSBuild.exe` для файла решения (`.sln`) или проекта (`.vcxproj`), ближайшего к корневому каталогу.\n   Если `autobuild` обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них.\n2. Вызов скрипта, который похож на скрипт сборки — *build.bat*, *build.cmd* и *build.exe* (в этом порядке).\n\n### Автоматическое обнаружение Linux и macOS\n\nНа Linux и macOS шаг `autobuild` проверяет наличие файлов в репозитории, чтобы определить используемую систему сборки:\n\n1. Поиск системы сборки в корневом каталоге.\n2. Если она не будет найдена, выполняется поиск по подкаталогам уникального каталога с системой сборки для C/C++.\n3. Выполнение соответствующей команду, чтобы настроить систему.\n\n#### Требования для запуска для C/C++\n\nВ запусках Ubuntu Linux может попытаться автоматически установить зависимости, `autobuild` необходимые для обнаруженных действий конфигурации и сборки. По умолчанию это поведение включено на GitHub-hosted runners и отключено на самостоятельных раннерах. Вы можете включить или отключить эту функцию явным образом, задав `CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES` или `true``false` в среде. Дополнительные сведения об определении переменных среды см. в разделе [Хранение сведений в переменных](/ru/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow).\n\nДля локальных модулей выполнения, если только автоматическая установка зависимостей не включена, скорее всего, потребуется установить `gcc` компилятор, а для конкретных проектов также может потребоваться доступ к `clang` исполняемым файлам или `msvc` файлам. Кроме того, необходимо установить систему сборки (например`msbuild`, , `make`, `cmake`, `bazel`) и служебные программы (например`python`, , `perl``lex`и `yacc`) от того, от сколько зависят проекты.\nЕсли включить автоматическую установку зависимостей, необходимо убедиться, что средство выполнения использует Ubuntu и может выполняться `sudo apt-get` без необходимости пароля.\n\nWindows бегунам требуется `powershell.exe` для `PATH`.\n\n## Сборка C\\#\n\nCodeQL поддерживает `none`режимы сборки , `autobuild` или `manual` для кода на C#.\n\nЕсли включить настройку по умолчанию для репозитория, содержащего код C#, режим сборки устанавливается `none` автоматически.\n\n### Сборка для C не выполняется\\#\n\nCodeQL восстанавливает зависимости и генерирует несколько дополнительных исходных файлов, чтобы получить более точные результаты, прежде чем создать базу данных из всех исходных файлов и зависимостей.\n\nЗависимости восстанавливаются с помощью нескольких эвристических и стратегий. Следующие файлы являются основным источником информации: `*.csproj`, `*.sln`, `nuget.config`, , `packages.config`и `global.json``project.assets.json`.\nЕсли для организации определена приватная лента NuGet, это также используется, см. [раздел «Сканирование кода, доступ к частным реестрам по умолчанию](/ru/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries) » и [«Определение, использовала ли настройка сканирования кода по умолчанию какие-либо приватные реестры](/ru/code-security/code-scanning/managing-your-code-scanning-configuration/viewing-code-scanning-logs#determining-whether-code-scanning-default-setup-used-any-private-registries)».\n\nСледующие сгенерированные исходные файлы являются необязательными, но значительно повышают корректность CodeQL базы данных:\n\n* `global` созданные `using` директивы для обработки неявной `using` функции MSbuild.\n* ASP.NET файлы ядра `.cshtml` преобразуются в `.cs` файлы.\n\nИнформация из имён ассемблеров зависимостей, сгенерированных исходных файлов, зависимостей, хранящихся в приватных лентах, и исходных файлов в репозитории, компилируется и используется для создания CodeQL базы данных.\n\n#### Точность анализа сборки для C\\#\n\nСоздание базы CodeQL данных без полного кода зависит от возможности восстанавливать зависимости и компиляции исходных файлов в репозитории. Когда возникают проблемы с восстановлением зависимостей или компиляцией исходного кода, это может повлиять на точность CodeQL базы данных и code scanning результаты анализа.\n\nВы можете обеспечить более точный анализ, выполнив следующие действия.\n\n* Обеспечьте доступ к публичному интернету или убедитесь, что доступен приватный канал NuGet, см. [раздел «Сканирование кода по умолчанию для настройки доступа к частным реестрам](/ru/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries)».\n* Проверьте, требуется ли репозиторию несколько версий одной зависимости NuGet.\n  CodeQL Можно использовать только одну версию и обычно выбирает более новую, где есть несколько версий. Этот подход может не работать для всех репозиториев.\n* Проверьте, упоминаются ли несколько версий .NET, например, `net48`, `net5.0` и `netstandard1.6`.\n  CodeQL можно использовать только одну версию, и это может повлиять на точность.\n* Избегайте сопоставления имен классов, в противном случае это может привести к отсутствием целевых объектов вызова метода, которые влияют на анализ потока данных.\n\n### Краткое описание автосборки для C\\#\n\n| Поддерживаемый тип системы | Системное имя                          |\n| -------------------------- | -------------------------------------- |\n| Операционная система       | Windows, macOS и Linux                 |\n| Система сборки             | .NET и MSbuild, а также скрипты сборки |\n\n#### Автоопределение Windows\n\nПроцесс `autobuild` пытается выполнить автоматическое определение подходящего метода сборки для C# с помощью следующего подхода:\n\n1. Вызов `dotnet build` для файла решения (`.sln`) или проекта (`.csproj`), ближайшего к корневому каталогу.\n2. `MSBuild.exe` Вызовите файл решения или проекта, ближайший к корневому каталогу.\n   Если `autobuild` обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них.\n3. Вызов скрипта, который выглядит как скрипт сборки,`build.bat``build.cmd` и `build.exe` (в этом порядке).\n\n#### Требования к бегу для C# на Windows\n\nДля разработки .NET Core приложения на самостоятельных раннерах требуется .NET SDK (для `dotnet`).\n\nДля разработки приложений .NET Framework вам понадобятся Microsoft Build Tools (для `msbuild`) и NuGet CLI (для `nuget`).\n\nWindows бегунам требуется `powershell.exe` для `PATH`.\n\nЕсли вы планируете создавать CodeQL базы данных с `build-mode: none`помощью , вам также необходимо предоставить доступ к публичному интернету или убедиться, что доступ к приватной ленте NuGet доступен.\n\n#### Автоматическое обнаружение Linux и macOS\n\n1. Вызов `dotnet build` для файла решения (`.sln`) или проекта (`.csproj`), ближайшего к корневому каталогу.\n2. `MSbuild` Вызовите файл решения или проекта, ближайший к корневому каталогу.\n   Если `autobuild` обнаруживает несколько файлов решения или проекта с одной и той же (самой короткой) глубиной относительно каталога верхнего уровня, он попытается собрать все из них.\n3. Вызов скрипта, который выглядит как скрипт сборки,`build` и `build.sh` (в этом порядке).\n\n#### Требования runner для C# в Linux и macOS\n\nДля разработки .NET Core приложения на самостоятельных раннерах требуется .NET SDK (для `dotnet`).\n\nДля разработки .NET фреймворк вам потребуется моно Runtime (для запуска `mono`, `msbuild` или `nuget`).\n\nЕсли вы планируете создавать CodeQL базы данных с `build-mode: none`помощью , вам также необходимо предоставить доступ к публичному интернету или убедиться, что доступ к приватной ленте NuGet доступен.\n\n### Флаги компилятора C#, инжектируемые CodeQL для ручных сборок\n\nТрассер позволяет извлекать все скомпилированные языки, перехватывая процессы CodeQL сборки и перенаправляя информацию соответствующим CodeQL языковым экстракторам. Трассер вводит определённые флаги в вызов компилятора C#, чтобы убедиться, что каждый компонент построен и включён в CodeQL базу данных, что может привести к тому, что ваш C#-код будет строиться иначе, чем вы ожидаете при CodeQL анализе.\n\n#### `/p:MvcBuildViews=true`\n\nКогда эта опция установлена в `true`, представления в проектах ASP.NET модель-просмотр-контроллер (MVC) предварительно компилируются в процессе сборки, что помогает обнаруживать ошибки и повышать производительность. Трассер вводит этот флаг, чтобы убедиться CodeQL , что он обнаруживает и выделяет проблемы безопасности, связанные с потоком данных через код, сгенерированный из этих видов. Дополнительные сведения см. в разделе [\"Добавление представления в приложение](https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/introduction/adding-a-view) MVC\" в Microsoft Learn.\n\n#### `/p:UseSharedCompilation=false`\n\nУстановка этого параметра для `false` отключения использования общей функции компиляции, что может привести к более медленному времени сборки.\n**Если `/p:UseSharedCompilation=false` не** указано, `msbuild` запускается процесс сервера компилятора, и все компиляция будет выполнена одним процессом. Однако CodeQL трассер зависит от анализа аргументов новых процессов.\n\n#### `/p:EmitCompilerGeneratedFiles=true`\n\nУстановка этого параметра для `true` выдачи созданных компилятором файлов во время процесса сборки. Этот параметр приводит к созданию дополнительных исходных файлов компилятора, которые используются для поддержки таких функций, как улучшенная поддержка регулярных выражений, сериализация и создание представлений веб-приложений. Эти созданные артефакты обычно не записываются на диск компилятором, но настраивают параметр принудительной `true` записи файлов на диск, и поэтому средство извлечения может обрабатывать файлы.\n\nДля некоторых устаревших проектов и проектов, использующих `.sqlproj` файлы, можно увидеть, что внедренное `/p:EmitCompilerGeneratedFiles=true` свойство приводит к непредвиденным проблемам `msbuild`. Дополнительные сведения об устранении неполадок см. в разделе [Непредвиденное сбой компилятора C#](/ru/code-security/code-scanning/troubleshooting-code-scanning/c-sharp-compiler-unexpectedly-failing).\n\n## Сборка Go\n\nCodeQL поддерживает `autobuild` режимы сборки или `manual` для Go кода.\n\n### Сводка по автостроке для Go\n\n| Поддерживаемый тип системы | Системное имя                                                                      |\n| -------------------------- | ---------------------------------------------------------------------------------- |\n| Операционная система       | Windows, macOS и Linux                                                             |\n| Система сборки             | Модули Go и Glide, а также скрипты сборки, `dep` включая скрипты Makefiles и Ninja |\n\n### Автоматическое обнаружение для Go\n\nПроцесс `autobuild` пытается выполнить автоматическое определение подходящих способов установки зависимостей, необходимых репозиторию Go перед извлечением всех `.go` файлов:\n\n1. `make`Вызовите или `ninja``./build``./build.sh` (в этом порядке) до тех пор, пока одна из этих команд не будет успешно выполнена, а последующий `go list ./...` также будет успешно выполнена, указывая, что установлены необходимые зависимости.\n2. Если ни одна из этих команд не выполнена успешно, найдите `go.mod``Gopkg.toml` или выполните `glide.yaml` (если поставщик не используется) `go get` или`dep ensure -v``glide install`, соответственно, попробуйте установить зависимости.\n3. Наконец, если файлы конфигураций для этих диспетчеров зависимостей не найдены, переупорядочение структуры каталога репозитория, подходящей для добавления `GOPATH`и использования `go get` для установки зависимостей. Структура каталогов возвращается к нормальной после завершения извлечения.\n4. Извлеките весь код Go в репозитории, аналогичный выполнению `go build ./...`.\n\n> \\[!NOTE]\n> Если использовать настройки по умолчанию, система будет искать `go.mod` файл для автоматической установки совместимой версии языка Go.\n\n### Параметры средства извлечения для Go\n\nПо умолчанию тестовый код (код в файлах заканчивается `_test.go`) не анализируется. Вы можете переопределить это с помощью опции `--extractor-option extract_tests=true` при CodeQL CLIиспользовании , или установив переменную `CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_TESTS` среды на `true`.\n\nКроме того, `vendor` каталоги по умолчанию исключены из CodeQL анализа Go. Вы можете переопределить это, передав `--extractor-option extract_vendor_dirs=true` опцию при использовании CodeQL CLI, или установив переменную `CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_VENDOR_DIRS` среды на `true`.\n\n## Создание Java и Kotlin\n\nCodeQL поддерживает следующие режимы сборки.\n\n* Java: `none`, `autobuild` или `manual`\n* Котлин: `autobuild` или `manual`\n\nКогда вы впервые включаете настройки репозитория по умолчанию, если обнаруживается только Java коде, режим сборки устанавливается на `none`. Если обнаруживается Kotlin или комбинация кода Java и Kotlin, то режим сборки устанавливается на `autobuild`.\n\nЕсли позже добавить код Kotlin в репозиторий, использующий `none` режим сборки, CodeQL анализ сообщает предупреждение, объясняющее, что Kotlin не поддерживается. Вам потребуется отключить настройку по умолчанию и повторно включить ее. При повторной настройке по умолчанию режим сборки изменится таким `autobuild` образом, чтобы оба языка могли быть проанализированы. Кроме того, вы можете измениться на расширенную настройку. Дополнительные сведения см. в разделе [Предупреждение. Обнаружены файлы X Kotlin в проекте, которые не удалось обработать без сборки](/ru/code-security/code-scanning/troubleshooting-code-scanning/kotlin-detected-in-no-build).\n\n### Нет сборки для Java\n\nCodeQL попытается запустить Gradle или Maven для извлечения точной информации о зависимости (но не для вызова сборки), прежде чем создать базу данных из всех Java существующих файлов. Каждый корневой файл проекта Maven или Gradle (скрипт сборки без скрипта сборки, присутствующих в каталоге предков), запрашивается сведения о зависимости, а более последние версии зависимостей предпочтительнее при возникновении столкновения. Для получения информации о требованиях к бегуну для участия в Maven или Gradle см. [Требования к бегуну для Java](#runner-requirements-for-java).\n\nЕсли для организации определен приватный реестр Maven, он также используется, см. [раздел «Код сканирование по умолчанию для настройки доступа к частным реестрам](/ru/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries) » и [«Определение, использует ли настройка сканирования кода по умолчанию какие-либо приватные реестры](/ru/code-security/code-scanning/managing-your-code-scanning-configuration/viewing-code-scanning-logs#determining-whether-code-scanning-default-setup-used-any-private-registries)».\n\n#### Точность анализа без билдов для Java\n\nСоздание базы данных CodeQL Java без сборки может дать менее точные результаты, чем использование `autobuild` или ручных шагов сборки, если:\n\n* Скрипты сборки Gradle или Maven не могут быть запрошены для получения информации о зависимостях, а догадки о зависимости (основанные на названиях пакетов Java) неточны.\n* Репозиторий обычно создает код во время процесса сборки. Это будет анализироваться, если создать CodeQL базу данных в другом режиме.\n\nВы можете обеспечить более точный анализ, выполнив следующие действия.\n\n* Предоставить доступ к публичному интернету или убедиться, что доступен доступ к частному хранилищу артефактов, см. [раздел «Сканирование кода по умолчанию для настройки доступа к частным реестрам](/ru/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries#code-scanning-default-setup-access-to-private-registries)».\n* Проверьте, требуется ли репозиторию несколько версий одной зависимости.\n  CodeQL Можно использовать только одну версию и обычно выбирает более новую, где есть несколько версий. Этот подход может не работать для всех репозиториев.\n* Проверьте, требуется ли более одной версии JDK API для разных исходных Java-файлов. Когда видно несколько версий, CodeQL буду использовать самую высокую версию, требуемую для любого скрипта сборки. Это может означать, что некоторые файлы, требующие более низкой версии JDK, будут частично проанализированы. Например, если некоторые файлы требуют JDK 8, но требование JDK 17 встречается в одном или нескольких скриптах сборки, CodeQL будет использоваться JDK 17. Все файлы, требующие JDK 8, и не удалось создать с помощью JDK 17, будут частично проанализированы.\n* Избегайте сопоставления имен классов (например, определения `org.myproject.Test`нескольких файлов), в противном случае это может привести к отсутствием целевых объектов вызова метода, что влияет на анализ потока данных.\n\n### Краткое описание автосборки для Java\n\n| Поддерживаемый тип системы | Системное имя                            |\n| -------------------------- | ---------------------------------------- |\n| Операционная система       | Windows, macOS и Linux (без ограничений) |\n| Система сборки             | Gradle, Maven и Ant                      |\n\n### Автообнаружение для Java\n\nПроцесс `autobuild` пытается определить систему сборки для Java кодовых баз, применяя следующую стратегию:\n\n1. Поиск файла сборки в корневом каталоге. Проверка наличия файлов сборки Gradle, затем Maven, а затем Ant.\n2. Запуск первого найденного файла сборки. Если присутствуют файлы и Gradle, и Maven, используется файл Gradle.\n3. В противном случае выполняется поиск файлов сборки в непосредственных подкаталогах корневого каталога. Если только один подкаталог содержит файлы сборки, запускается первый файл, определенный в этом подкаталоге (используя тот же приоритет, что и для 1). Если несколько подкаталогов содержат файлы сборки, возникает об ошибка.\n\n### Требования к бегу для Java\n\nЕсли вы используете самостоятельные раннеры, должны быть представлены необходимые версии Java:\n\n* Если раннер будет использоваться для анализа репозиториев, которым нужна одна версия Java, то необходимо установить соответствующую версию JDK, которая должна быть представлена в переменной PATH (чтобы можно было найти `java` и `javac`).\n\n* Если раннер будет использоваться для анализа репозиториев, требующих нескольких версий Java, необходимо установить соответствующие версии JDK, которые можно задать через файл `toolchains.xml`. Это файл конфигурации, обычно используемый Apache Maven, который позволяет указать расположение инструментов, версию средств и любую дополнительную конфигурацию, необходимую для использования средств. Дополнительные сведения см. в руководстве [по использованию цепочки](https://maven.apache.org/guides/mini/guide-using-toolchains.html) инструментов в документации Apache Maven.\n\nСледующие исполняемые файлы, вероятно, будут необходимы для ряда Java-проектов и должны присутствовать в переменной PATH, но они не будут обязательны во всех случаях:\n\n* `mvn` (Апач Мейвен)\n* `gradle` (Градл)\n* `ant` (Муравей-апач)\n\nКроме того, необходимо установить систему сборки (например`make`, , `cmake`) и служебные программы (например`bazel`, `python`,`perl``lex`, и`yacc`) от того, от сколько зависят ваши проекты.\n\nWindows бегунам требуется `powershell.exe` для `PATH`.\n\n## Строительная ржавчина\n\nCodeQL поддерживает режим `none` сборки для кода Rust.\n\n### Нет сборки для Rust\n\nCodeQL Используется `rust-analyzer` для компиляции и запуска скриптов сборки (`build.rs` файлов) и компиляции макрокода, но не вызывает полноценную сборку. База данных создается из всех присутствующих файлов Rust. Файл или `Cargo.toml``rust-project.json` должен присутствовать.\n\n### Требования к раннеру для Rust\n\nАнализ ржавчины требует `rustup` и `cargo` должен быть установлен.\n\n## Создание Swift\n\nCodeQL поддерживает режимы `autobuild` сборки или `manual` код на Swift.\n\n### Сводка по автостроке для Swift\n\n| Поддерживаемый тип системы | Системное имя |\n| -------------------------- | ------------- |\n| Операционная система       | macOS         |\n| Система сборки             | Xcode         |\n\nПроцесс `autobuild` пытается создать самый большой целевой объект из проекта или рабочей области Xcode.\n\nСканирование кода Swift использует средства выполнения macOS по умолчанию.\nПоскольку раннеры на GitHub стоят дороже Linux и Windows раннеров, мы рекомендуем создавать только тот код, который вы хотите анализировать. Для получения дополнительной информации о ценах для GitHub-hosted runners см. [Биллинг GitHub Actions](/ru/billing/managing-billing-for-github-actions/about-billing-for-github-actions).\n\nCode scanning Код Swift не поддерживается для runners, которые являются частью Actions Runner Controller (ARC), так как для выполнения ARC используются только Linux и Swift, требуются средства выполнения macOS. Тем не менее, вы можете иметь смесь как runners ARC, так и локальных модулей macOS runners. Дополнительные сведения см. в разделе [Контроллер runner действий](/ru/actions/concepts/runners/actions-runner-controller).\n\n### Кастомизация компиляции Swift в Рабочий процесс анализа CodeQL\n\n`xcodebuild` и `swift build` поддерживаются для сборок Swift. Рекомендуется использовать только одну архитектуру во время сборки. Например, `ARCH=arm64` для `xcodebuild`или `--arch arm64` для `swift build`.\n\nВы можете передать параметры `archive` и `test` параметры `xcodebuild`. Однако рекомендуется стандартная `xcodebuild` команда, так как она должна быть самой быстрой и достаточной CodeQL для успешного сканирования.\n\nДля быстрого анализа всегда необходимо явно устанавливать зависимости, управляемые через CocoaPods или Carthage, прежде чем создавать базу CodeQL данных."}