CodeQL documentation

test run


codeql test run [--threads=<num>] [--ram=<MB>] <options>... [--] <test|dir>...


Run unit tests for QL queries.



Each argument is one of:

  • A .ql or .qlref file that defines a test to run.
  • A directory which will be searched recursively for tests to run.

[Advanced] Set the exit code to produce if any failures are encountered. Usually 1, but tooling that parses the output may find it useful to set it to 0.


Select output format. Possible choices:

  • text for a human-readable textual rendering (default),
  • json for a streamed JSON array of objects, and
  • jsonz for a stream of zero-terminated JSON objects.

[Advanced] Preserve the databases extracted to run the test queries, even where all tests in a directory pass. (The database will always be left present when there are tests that fail).


[Advanced] Omit particularly slow optimization steps when compiling test queries. (Beware: there are many of the standard tests where this makes execution of the test infeasibly slow).


[Advanced] When a test produces unexpected output, instead of failing it, update its .expected file to match the actual output, such that it passes. Tests can still fail in this mode, for example if creation of a test database to query does not succeed.


[Advanced] A directory with consistency queries that will be run for each test database. These queries should not produce any output (except when they find a problem) unless the test directory includes a CONSISTENCY subdirectory with a .expected file. This is mostly useful for testing extractors.


[Advanced] Run codeql dataset check over each test database created and report a failure if it detects inconsistencies. This is useful when testing extractors. If the check is (temporarily!) expected to fail for a particular database, place a DB-CHECK.expected file in the test directory.


[Advanced] Show the output from extractor scripts that create test databases. This can be useful while developing or editing test cases. Beware that it can cause duplicated or malformed output if you use this with multiple threads!

-M, --ram=<MB>

Set total amount of RAM the test runner should be allowed to use.


[Advanced] Divide the test cases into M roughly equal-sized slices and process only the Nth of them. This can be used for manual parallelization of the testing process.


[Advanced] Only use queries that can be strongly identified as tests. This mode tries to distinguish between .ql files that define unit tests and .ql files that are meant to be useful queries. This option is used by tools, such as IDEs, that need to identify all unit tests in a directory tree without depending on previous knowledge of how the files in it are arranged.

Within a QL pack whose qlpack.yml declares a tests directory, all .ql files in that directory are considered tests, and .ql files outside it are ignored. In a QL pack that doesn’t declare a tests directory, a .ql file is identified as a test only if it has a corresponding .expected file.

For consistency, .qlref files are limited by the same rules as .ql files even though a .qlref file cannot really be a non-test.

Options to find libraries and extractors used by the tests


A list of directories under which QL packs may be found. Each directory can either be a QL pack (or bundle of packs containing a .codeqlmanifest.json file at the root) or the immediate parent of one or more such directories.

If the path contains more than one directory, their order defines precedence between them: when a pack name that must be resolved is matched in more than one of the directory trees, the one given first wins.

Pointing this at a checkout of the open-source CodeQL repository ought to work when querying one of the languages that live there.

If you have have checked out the CodeQL repository as a sibling of the unpacked CodeQL toolchain, you don’t need to give this option; such sibling directories will always be searched for QL packs that cannot be found otherwise. (If this default does not work, it is strongly recommended to set up --search-path once and for all in a per-user configuration file).

(Note: On Windows the path separator is ;).


If this list of directories is given, they will be searched for packs before the ones in --search-path. The order between these doesn’t matter; it is an error if a pack name is found in two different places through this list.

This is useful if you’re temporarily developing a new version of a pack that also appears in the default path. On the other hand, it is not recommended to override this option in a config file; some internal actions will add this option on the fly, overriding any configured value.

(Note: On Windows the path separator is ;).


[Advanced] An optional list of directories that will be added to the raw import search path for QL libraries. This should only be used if you’re using QL libraries that have not been packaged as QL packs.

(Note: On Windows the path separator is ;).


[Advanced] Explicitly define which dbscheme queries should be compiled against. This should only be given by callers that are extremely sure what they’re doing.


[Advanced] Specify an additional directory to use as a compilation cache.


[Advanced] Don’t use compilation caches in standard locations such as in the QL pack containing the query or in the CodeQL toolchain directory.

Options for configuring the CodeQL package manager


Accept a GitHub Apps token or personal access token via standard input.

This overrides the GITHUB_TOKEN environment variable.

Options that control the evaluation of test queries


[Advanced] Display tuple counts for each evaluation step in the query evaluator logs. If the --evaluator-log option is provided, tuple counts will be included in both the text-based and structured JSON logs produced by the command. (This can be useful for performance optimization of complex QL code).


[Advanced] Set the timeout length for query evaluation, in seconds.

The timeout feature is intended to catch cases where a complex query would take “forever” to evaluate. It is not an effective way to limit the total amount of time the query evaluation can take. The evaluation will be allowed to continue as long as each separately timed part of the computation completes within the timeout. Currently these separately timed parts are “RA stages” of the optimized query, but that might change in the future.

If no timeout is specified, or is given as 0, no timeout will be set (except for codeql test run, where the default timeout is 5 minutes).

-j, --threads=<num>

Use this many threads to evaluate queries.

Defaults to 1. You can pass 0 to use one thread per core on the machine, or -N to leave N cores unused (except still use at least one thread).

Options for controlling outputting of structured evaluator logs


[Advanced] Output structured JSON logs about evaluator performance to the given file. The format of this log file is subject to change with no notice. Please use codeql generate log-summary <file> to produce a more stable summary of this file, and avoid parsing the file directly. The file will be overwritten if it already exists.


[Advanced] If the --evaluator-log option is passed, also passing this option will minimize the size of the JSON log produced, at the expense of making it much less human readable.


[Advanced] If the --evaluator-log option is passed, also passing this option will configure the verbosity of the JSON log produced. This should be an integer between 1 and 5, with higher values representing a higher verbosity. Currently the following additional values will be included at each level (in addition to all information already present in preceding levels):

  • Level 1: Include basic information about each computation performed by the evaluator. This is the default verbosity level if this option is not passed.
  • Level 2: Include the dependencies of every layer that is computed.
  • Level 3: Include details of where each layer is used.
  • Level 4: Record an event when we hit the cache and do not compute a predicate.
  • Level 5: Output the full RA of any relations that are evaluated.

Options for checking imported TRAP


[Advanced] Report errors for undefined labels.


[Advanced] Report errors for unused labels.


[Advanced] Report errors for repeated labels.


[Advanced] Report errors for redefined labels.


[Advanced] Report errors for labels used before they’re defined.


[Advanced] Exit non-zero if an error occurs during trap import.


[Advanced] Construct entity IDs that encode the location in the TRAP file they came from. Can be useful for debugging of TRAP generators, but takes up a lot of space in the dataset.

Common options

-h, --help

Show this help text.


[Advanced] Give option to the JVM running the command.

(Beware that options containing spaces will not be handled correctly.)

-v, --verbose

Incrementally increase the number of progress messages printed.

-q, --quiet

Incrementally decrease the number of progress messages printed.


[Advanced] Explicitly set the verbosity level to one of errors, warnings, progress, progress+, progress++, progress+++. Overrides -v and -q.


[Advanced] Write detailed logs to one or more files in the given directory, with generated names that include timestamps and the name of the running subcommand.

(To write a log file with a name you have full control over, instead give --log-to-stderr and redirect stderr as desired.)

  • © GitHub, Inc.
  • Terms
  • Privacy