ノート: Code scanningは現在ベータで、変更されることがあります。 To request access to the beta, join the waitlist.
If an automatic build of code for a compiled language within your project fails, try the following troubleshooting steps.
- Remove the
autobuildstep from your code scanning workflow and add specific build steps. For information about editing the workflow, see "Configuring code scanning." For more information about replacing the
autobuildstep, see "Configuring the CodeQL workflow for compiled languages."
- If the repository for your project contains code in a specific language that does not build, disable automatic language detection in your code scanning workflow and specify only the languages you want to build. For more information, see "Configuring code scanning."
If your workflow fails with an error
No source code was seen during the build or
The process '/opt/hostedtoolcache/CodeQL/0.0.0-20200630/x64/codeql/codeql' failed with exit code 32, this indicates that CodeQL was unable to trace your code. Several reasons can explain such a failure:
Automatic language detection identified a supported language, but there is no analyzable code of that language in the repository. A typical example is when our language detection service finds a file associated with a particular programming language like a
.gypfile, but no corresponding executable code is present in the repository. To solve the problem, you can manually define the languages you want to analyze by updating the
Your code scanning workflow is analyzing a compiled language (C, C++, C#, or Java), but the code was not compiled. By default, the CodeQL analysis workflow contains an
autobuildstep, however, this step represents a best effort process, and may not succeed in building your code, depending on your specific build environment. Compilation may also fail if you have removed the
autobuildstep and did not include build steps manually. For more information about specifying build steps, see "Configuring the CodeQL workflow for compiled languages."
Your workflow is analyzing a compiled language (C, C++, C#, or Java), but portions of your build are cached to improve performance (most likely to occur with build systems like Gradle or Bazel). Since CodeQL observes the activity of the compiler to understand the data flows in a repository, CodeQL requires a complete build to take place in order to perform analysis.
Your workflow is analyzing a compiled language (C, C++, C#, or Java), but compilation does not occur between the
analyzesteps in the workflow. CodeQL requires that your build happens in between these two steps in order to observe the activity of the compiler and perform analysis.
Your compiled code (in C, C++, C#, or Java) was compiled successfully, but CodeQL was unable to detect the compiler invocations. The most common causes are certain configuration options like running your build process in a container, if you're building using a distributed build system external to GitHub Actions using a daemon process, or if CodeQL isn't aware of the specific compiler you are using.
For C# projects using either
msbuildwhich target .NET Core 2, you should specify
/p:UseSharedCompilation=falsein your workflow's
runstep, when you build your code. The
UseSharedCompilationflag isn't necessary for .NET Core 3.0 and later.
For example, the following configuration will pass the flag during the first build step.
- run: | dotnet build /p:UseSharedCompilation=false
For more information about specifying build steps, see "Configuring the CodeQL workflow for compiled languages."
autobuild feature uses heuristics to build the code in a repository, however, sometimes this approach results in incomplete analysis of a repository. For example, when multiple
build.sh commands exist in a single repository, the analysis may not complete since the
autobuild step will only execute one of the commands. The solution is to replace the
autobuild step with build steps which build all of the source code which you wish to analyze. Alternatively, if more than one compiled language is present in your repository and you want code scanning to analyze all these compiled languages, you can use a build matrix in your workflow. For more information, see "Managing complex workflows" and
"Configuring the CodeQL action for compiled languages."
On very large projects, CodeQL may run out of disk or memory on the runner. If you encounter this issue on a hosted GitHub Actions runner, contact GitHub Supportまたは GitHub Premium Support so that we can investigate the problem.
If your build with CodeQL analysis takes too long to run, there are several approaches you can try to reduce the build time.
If you use self-hosted runners to run CodeQL analysis, you can increase the memory or the number of cores on those runners.
By default, CodeQL performs analysis of each language sequentially, which can impact performance, especially for repositories with more than one language. You can speed analysis up by using a build matrix that splits the analysis by language. For more information, see "Managing complex workflows."
Analysis time is typically proportional to the amount of code being analyzed. You can reduce the analysis time by reducing the amount of code being analyzed at once, for example, by excluding test code, or breaking analysis into multiple workflows that analyze only a subset of your code at a time.
For compiled languages like Java, C, C++, and C#, CodeQL analyzes all of the code which was built during the workflow run. To limit the amount of code being analyzed, build only the code which you wish to analyze by specifying your own build steps in a
run block. You can combine specifying your own build steps with using the
paths-ignore filters on the
push events to ensure that your workflow only runs when specific code is changed. For more information, see "Workflow syntax for GitHub Actions."
If you split your analysis into multiple workflows as described above, we still recommend that you have at least one workflow which runs on a
schedule which analyzes all of the code in your repository. Because CodeQL analyzes data flows between components, some complex security behaviors may only be detected on a complete build.
If your analysis is still too slow to be run during
pull_request events, then you may want to only trigger analysis on the
schedule event. For more information, see "Events."