14 KiB
title, shortTitle, intro, product, permissions, redirect_from, versions, type, topics
| title | shortTitle | intro | product | permissions | redirect_from | versions | type | topics | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CodeQL code scanning for compiled languages | CodeQL for compiled languages | You can configure how {% data variables.product.prodname_dotcom %} uses the {% data variables.code-scanning.codeql_workflow %} to scan code written in compiled languages for vulnerabilities and errors. You can also use default setup for all compiled languages{% ifversion codeql-swift-advanced-setup %} (except for Swift, for which you must use advanced setup){% endif %}, which requires no {% data variables.code-scanning.codeql_workflow %} configuration. | {% data reusables.gated-features.code-scanning %} | If you have write permissions to a repository, you can configure {% data variables.product.prodname_code_scanning %} for that repository. |
|
|
how_to |
|
{% data reusables.code-scanning.beta %} {% data reusables.code-scanning.enterprise-enable-code-scanning-actions %}
About the {% data variables.code-scanning.codeql_workflow %} and compiled languages
{% data variables.product.prodname_code_scanning_caps %} works by running queries against one or more databases. Each database contains a representation of all of the code in a single language in your repository. For the compiled languages {% data variables.code-scanning.compiled_languages %}, the process of populating this database involves building the code and extracting data.
{% data reusables.code-scanning.autobuild-compiled-languages %}
{% ifversion code-scanning-without-workflow-310 %}
For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you can use default setup, which analyzes your code and automatically configures your {% data variables.product.prodname_code_scanning %}, or advanced setup, which generates a workflow file you can edit. Default setup can analyze all compiled languages supported by {% data variables.product.prodname_codeql %}{% ifversion codeql-swift-advanced-setup %} except for Swift, for which you must use advanced setup{% endif %}. For more information about advanced setup, see "AUTOTITLE."
{% elsif code-scanning-without-workflow %}
For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you can use default setup, which analyzes your code and automatically configures your {% data variables.product.prodname_code_scanning %}, or advanced setup, which generates a workflow file you can edit. Default setup does not support any compiled languages, so you must use advanced setup. For more information, see "AUTOTITLE."
{% else %}
You set up {% data variables.product.prodname_dotcom %} to run {% data variables.product.prodname_code_scanning %} for your repository by adding a {% data variables.product.prodname_actions %} workflow to the repository. For {% data variables.product.prodname_codeql %} {% data variables.product.prodname_code_scanning %}, you add the {% data variables.code-scanning.codeql_workflow %}. For more information, see "AUTOTITLE."
{% endif %}
If your workflow uses a language matrix, autobuild attempts to build each of the compiled languages listed in the matrix. Without a matrix autobuild attempts to build the supported compiled language that has the most source files in the repository. With the exception of Go, analysis of other compiled languages in your repository will fail unless you supply explicit build commands.
About autobuild for {% data variables.product.prodname_codeql %}
{% data reusables.code-scanning.autobuild-compiled-languages %}
autobuildfor C/C++autobuildfor C#{% ifversion codeql-go-autobuild %}autobuildfor Go{% endif %}{% ifversion codeql-kotlin-beta %}autobuildfor Java and Kotlin{% else %}autobuildfor Java{% endif %}{% ifversion codeql-swift-beta %}autobuildfor Swift{% endif %}
{% note %}
{% ifversion ghae %}
Note: {% data reusables.actions.self-hosted-runners-software %}
{% else %}
Note: If you use self-hosted runners for {% data variables.product.prodname_actions %}, you may need to install additional software to use the autobuild process. Additionally, if your repository requires a specific version of a build tool, you may need to install it manually. For more information, see "AUTOTITLE".
{% endif %}
{% endnote %}
autobuild for C/C++
| Supported system type | System name |
|---|---|
| Operating system | Windows, macOS, and Linux |
| Build system | Windows: MSbuild and build scripts Linux and macOS: Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild, and build scripts |
The behavior of the autobuild step varies according to the operating system that the extraction runs on. On Windows, the autobuild step attempts to autodetect a suitable build method for C/C++ using the following approach:
- Invoke
MSBuild.exeon the solution (.sln) or project (.vcxproj) file closest to the root. Ifautobuilddetects multiple solution or project files at the same (shortest) depth from the top level directory, it will attempt to build all of them. - Invoke a script that looks like a build script—build.bat, build.cmd, and build.exe (in that order).
On Linux and macOS, the autobuild step reviews the files present in the repository to determine the build system used:
- Look for a build system in the root directory.
- If none are found, search subdirectories for a unique directory with a build system for C/C++.
- Run an appropriate command to configure the system.
autobuild for C#
| Supported system type | System name |
|---|---|
| Operating system | Windows and Linux |
| Build system | .NET and MSbuild, as well as build scripts |
The autobuild process attempts to autodetect a suitable build method for C# using the following approach:
- Invoke
dotnet buildon the solution (.sln) or project (.csproj) file closest to the root. - Invoke
MSbuild(Linux) orMSBuild.exe(Windows) on the solution or project file closest to the root. Ifautobuilddetects multiple solution or project files at the same (shortest) depth from the top level directory, it will attempt to build all of them. - Invoke a script that looks like a build script—build and build.sh (in that order, for Linux) or build.bat, build.cmd, and build.exe (in that order, for Windows).
{% ifversion codeql-go-autobuild %}
autobuild for Go
| Supported system type | System name |
|---|---|
| Operating system | Windows, macOS, and Linux |
| Build system | Go modules, dep and Glide, as well as build scripts including Makefiles and Ninja scripts |
The autobuild process attempts to autodetect a suitable way to install the dependencies needed by a Go repository before extracting all .go files:
- Invoke
make,ninja,./buildor./build.sh(in that order) until one of these commands succeeds and a subsequentgo list ./...also succeeds, indicating that the needed dependencies have been installed. - If none of those commands succeeded, look for
go.mod,Gopkg.tomlorglide.yaml, and rungo get(unless vendoring is in use),dep ensure -vorglide installrespectively to try to install dependencies. - Finally, if configurations files for these dependency managers are not found, rearrange the repository directory structure suitable for addition to
GOPATH, and usego getto install dependencies. The directory structure reverts to normal after extraction completes. - Extract all Go code in the repository, similar to running
go build ./....
{% endif %}
autobuild for Java {% ifversion codeql-kotlin-beta %} and Kotlin {% endif %}
| Supported system type | System name |
|---|---|
| Operating system | Windows, macOS, and Linux (no restriction) |
| Build system | Gradle, Maven and Ant |
The autobuild process tries to determine the build system for Java codebases by applying this strategy:
- Search for a build file in the root directory. Check for Gradle then Maven then Ant build files.
- Run the first build file found. If both Gradle and Maven files are present, the Gradle file is used.
- Otherwise, search for build files in direct subdirectories of the root directory. If only one subdirectory contains build files, run the first file identified in that subdirectory (using the same preference as for 1). If more than one subdirectory contains build files, report an error.
{% ifversion codeql-swift-beta %}
autobuild for Swift
| Supported system type | System name |
|---|---|
| Operating system | macOS |
| Build system | Xcode |
The autobuild process tries to build the biggest target from an Xcode project or workspace.
For more information about building Swift code, see "Considerations for building Swift." {% endif %}
{% ifversion codeql-swift-beta %}
Considerations for building Swift
{% data reusables.code-scanning.beta-swift-support %}
Code scanning of Swift code uses macOS runners by default. {% ifversion fpt or ghec %}Since {% data variables.product.company_short %}-hosted macOS runners are more expensive than Linux and Windows runners, we recommend that you build only the code that you want to analyze. For more information about pricing for {% data variables.product.company_short %}-hosted runners, see "AUTOTITLE."{% endif %}
Code scanning of Swift code is not supported for runners that are part of an Actions Runner Controller (ARC), but you can have a mixture of both ARC runners and self-hosted macOS runners. For more information, see "AUTOTITLE."
xcodebuild and swift build are both supported for Swift builds. We recommend only targeting one architecture during the build. For example, ARCH=arm64 for xcodebuild, or --arch arm64 for swift build.
You can pass the archive and test options to xcodebuild. However, the standard xcodebuild command is recommended as it should be the fastest, and should be all that {% data variables.product.prodname_codeql %} requires for a successful scan.
For Swift analysis, you must always explicitly install dependencies managed via CocoaPods or Carthage before generating the {% data variables.product.prodname_codeql %} database.
For Swift, the autobuild process tries to build the biggest target from an Xcode project or workspace.
{% endif %}
Adding build steps for a compiled language
{% data reusables.code-scanning.autobuild-add-build-steps %} For information on how to edit the workflow file, see "AUTOTITLE."
After removing the autobuild step, uncomment the run step and add build commands that are suitable for your repository. The workflow run step runs command-line programs using the operating system's shell. You can modify these commands and add more commands to customize the build process.
- run: |
make bootstrap
make release
For more information about the run keyword, see "AUTOTITLE."
If your repository contains multiple compiled languages, you can specify language-specific build commands. For example, if your repository contains C/C++, C# and Java, and autobuild correctly builds C/C++ and C# but fails to build Java, you could use the following configuration in your workflow, after the init step. This specifies build steps for Java while still using autobuild for C/C++ and C#:
- if: matrix.language == 'cpp' || matrix.language == 'csharp'
name: Autobuild
uses: {% data reusables.actions.action-codeql-action-autobuild %}
- if: matrix.language == 'java'
name: Build Java
run: |
make bootstrap
make release
For more information about the if conditional, see "AUTOTITLE."
For more tips and tricks about why autobuild won't build your code, see "AUTOTITLE."
If you added manual build steps for compiled languages and {% data variables.product.prodname_code_scanning %} is still not working on your repository, contact {% data variables.contact.contact_support %}.