Note: This documentation is for the legacy command-line tool odasa.
The final version was released in May 2020. Support for this tool expires in May 2021.

For documentation on the new generation CodeQL CLI, see CodeQL CLI .
In particular, you may find the Notes for legacy QL CLI users useful in planning your migration.

Skip to end of metadata
Go to start of metadata



This topic describes how to enable the prototyping mode when you troubleshoot the process of building the code for a project.

Task overview

When you are setting up analysis and have problems building the code for a project, you may find it useful to use the prototyping mode. This mode is designed to simplify troubleshooting a process which fails during one or more steps.

Enabling the prototyping mode

Set an environment variable called ODASA_PROTOTYPE_MODE to true:

On Linux and OS X (bash)
On Windows

You use these scripts instead of using the standard or setup.bat setup scripts.

Behavior of buildSnapshot in prototyping mode

When you enable prototyping mode for the Semmle environment it affects the default behavior of the buildSnapshot command. It will always keep the snapshot build files even when an unrecoverable error occurs (as if you have specified the --ignore-errors .flag). This means that you can look at the build files and logs to troubleshoot the process without first needing to unzip a archive. In addition, the command will not run unless you specify the --overwrite flag if the following directories are not empty: the trap folder, the database folder, the source archive, the results folder (normally any content is silently deleted). This reduces the chances that you will overwrite partial results accidentally.

Building new projects

After you have enabled prototyping mode, you are ready to build projects for new code bases using the standard methods. Please see the following topics for more information:

If the buildSnapshot command fails at any step then the commands do not perform the normal archive and delete steps—the incomplete files are available for examination immediately. This makes it easier to diagnose the reason for any build failure (perhaps the code base is large and requires more RAM or a longer timeout to enable the analysis to succeed).

In addition, if the build process fails during trap import then you can re-run the buildSnapshot command with the --skip-build flag to resume the import of trap files and finalization of the snapshot database ready for analysis. A failure at this point is not uncommon if the code base is too large for the value of the ram element in the project configuration file, because trap import is the most memory-intensive part of a snapshot build. It may also happen later if you run out of disk while creating the database.

Known limitations

None known.

  • No labels