Nota: El Ejecutor de CodeQL se va a obsoletizar. En GitHub Enterprise Server 3.0 y superior, puedes instalar el CodeQL CLI versión 2.6.3 para reemplazar el Ejecutor de CodeQL.
Para obtener más información, consulta la obsoletización del ejecutor de CodeQL. Para obtener más información sobre cómo migrarse al CodeQL CLI, consulta la sección "Migrarse desde el ejecutor de CodeQL al CLI de CodeQL".
The init
command takes too long
Before the Ejecutor de CodeQL can build and analyze code, it needs access to the CodeQL bundle, which contains the CodeQL CLI and the CodeQL libraries.
When you use the Ejecutor de CodeQL for the first time on your machine, the init
command downloads the CodeQL bundle to your machine. This download can take a few minutes.
The CodeQL bundle is cached between runs, so if you use the Ejecutor de CodeQL again on the same machine, it won't download the CodeQL bundle again.
To avoid this automatic download, you can manually download the CodeQL bundle to your machine and specify the path using the --codeql-path
flag of the init
command.
No code found during the build
If the analyze
command for the Ejecutor de CodeQL fails with an error No source code was seen during the build
, this indicates that CodeQL was unable to monitor 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
.h
, or.gyp
file, 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 using the--languages
flag of theinit
command. For more information, see "Configuring Ejecutor de CodeQL in your CI system." -
You're analyzing a compiled language without using the
autobuild
command and you run the build steps yourself after theinit
step. For the build to work, you must set up the environment such that the Ejecutor de CodeQL can monitor the build process. Theinit
command generates instructions for how to export the required environment variables, so you can copy and run the script after you've run theinit
command.- On macOS and Linux:
$ . codeql-runner/codeql-env.sh
- On Windows, using the Command shell (
cmd
) or a batch file (.bat
):> call codeql-runner\codeql-env.bat
- On Windows, using PowerShell:
> cat codeql-runner\codeql-env.sh | Invoke-Expression
The environment variables are also stored in the file
codeql-runner/codeql-env.json
. This file contains a single JSON object which maps environment variable keys to values. If you can't run the script generated by theinit
command, then you can use the data in JSON format instead.Note:� If you used the
--temp-dir
flag of theinit
command to specify a custom directory for temporary files, the path to thecodeql-env
files might be different. - On macOS and Linux:
-
You're analyzing a compiled language on macOS without using the
autobuild
command and you run the build steps yourself after theinit
step. If SIP (System Integrity Protection) is enabled, which is the default on recent versions of OSX, analysis might fail. To fix this, prefix the build command with the$CODEQL_RUNNER
environment variable. For example, if your build command iscmd arg1 arg2
, you should run$CODEQL_RUNNER cmd arg1 arg2
. -
The code is built in a container or on a separate machine. If you use a containerized build or if you outsource the build to another machine, make sure to run the Ejecutor de CodeQL in the container or on the machine where your build task takes place. For more information, see "Running CodeQL code scanning in a container."