Skip to main content

Enterprise Server 3.15 в настоящее время доступен в качестве кандидата на выпуск.

Ошибка: "Во время сборки не было видно исходного кода"

Если CodeQL не удается найти исходный код, необходимо устранить эту проблему, чтобы разблокировать анализ code scanning.

Если рабочий процесс завершается сбоем Error: "No source code was seen during the build" или The process '/opt/hostedtoolcache/CodeQL/0.0.0-20200630/x64/codeql/codeql' failed with exit code 32означает, что CodeQL не удалось отслеживать код. Существует шесть возможных причин для этого:

  1. Нет поддерживаемых языков: репозиторий не может содержать исходный код, написанный на языках, поддерживаемых CodeQL. Проверьте список поддерживаемых языков и, если дело в этом, удалите рабочий процесс CodeQL. Дополнительные сведения см. в разделе О проверке кода с помощью CodeQL.

  2. Нет анализируемого кода обнаруженных языков: автоматическое обнаружение языка определило поддерживаемый язык, но в репозитории нет анализимого кода этого языка. Типичный пример — служба определения языка находит файл, связанный с определенным языком, например файл .h или .gyp, но в репозитории отсутствует соответствующий исполняемый код. Чтобы решить эту проблему, можно вручную определить языки, которые требуется проанализировать, обновив список языков в матрице language. Например, следующая конфигурация проанализирует только Go и JavaScript.

    strategy:
      fail-fast: false
      matrix:
        # Override automatic language detection by changing the list below.
        # Supported options are listed in a comment in the default workflow.
        language: ['go', 'javascript-typescript']
    

    Дополнительные сведения см. в извлечении рабочего процесса в autoTITLE.

  3. Сбой компиляции скомпилированного языка: рабочий процесс code scanning пытается скомпилировать скомпилированный язык (C,C++, C#, Go или Java), но код не компилировался. Если рабочий процесс задает build-mode: autobuild язык или содержит autobuild шаг, CodeQL делает все возможное, чтобы определить подходящий метод сборки и построить код. Процесс autobuild может не завершиться сборкой кода в зависимости от конкретной среды сборки. Компиляция также может завершиться ошибкой, если вы удалили этот шаг autobuild и не включили шаги сборки вручную. Дополнительные сведения об определении шагов сборки см. в разделе "[AUTOTITLE".

  4. Кэшированные компоненты не обнаружены: рабочий процесс создает скомпилированный язык (C, C++, C#, Go или Java), чтобы создать базу данных CodeQL для анализа, но части сборки кэшируются для повышения производительности (скорее всего, с системами сборки, такими как Gradle или Bazel). Поскольку CodeQL наблюдает за активностью компилятора, чтобы распознать потоки данных в репозитории, для CodeQL требуется полная сборка для выполнения анализа.

  5. Компиляция вне init и analyze этапов. Рабочий процесс создает скомпилированный язык (C,C++, C#, Go или Java), но компиляция не выполняется между analyze init этапами рабочего процесса. Для CodeQL требуется выполнение сборки между этими двумя шагами, чтобы наблюдать за активностью компилятора и выполнять анализ.

  6. Компиляция не обнаружена CodeQL: скомпилированный код (в C, C++, C#, C#, Go или Java), но CodeQL не удалось обнаружить вызовы компилятора. Ниже перечислены наиболее распространенные из них.

    • Выполнение процесса сборки в отдельном контейнере для CodeQL. Дополнительные сведения см. в разделе Выполнение проверки кода CodeQL в контейнере.
    • Создание с помощью распределенной системы сборки, внешней для функции GitHub Actions, использующей процесс управляющей программы.
    • CodeQL не знает об используемом конкретном компиляторе.

Если возникла другая проблема с конкретным компилятором или конфигурацией, обратитесь в ваш администратор сайта.

Дополнительные сведения об указании шагов сборки см. в разделе "Сканирование кода CodeQL для скомпилированных языков".