This is still an intermediate step as we start to bring in more
abstractions. I plan to implement a storage handler that will
keep track of all the different bits for a remote query.
This change builds on the previous change to ensure that sarif results
can be displayed properly. Here is what it does:
- Move prepareDownloadDirectory to the RemoteQueryManager
- Store the queryResult to disk
- Use the `artifactStorageDir` as the location where artifacts are kept
- Add `artifactStorageDir` to DownloadLink
- Ensure the webview passes around the right links.
This moves all artifacts downloaded for a remote query into the global
storage directory. Each remote query gets its own directory. The
parent directory is the shared query storage directory.
Each remote query directory also gets a timestamp file.
With these changes, remote queries will be persisted across restarts
and deleted automatically on the same schedule as local queries.
Note: This does _not_ add remote queries to the query history view yet.
This part of the feature is coming next.
There is no new behaviour added in this commit. Just some cleanup:
- Move some shared constants to the `helpers` module
- Add comments to some of the query related modules
- Some general formatting and tidying
Ensure that upgrades can be resolved even when the upgrades pack is not
in the workspace. This is the situation when the core libraries are
resolved from the package cache.
This change works because `qlProgram.libraryPath` is the resolved
search path for compiling the query. We are guaranteed that the
appropriate core libraries are included in this query.
Note that this change avoids using extra source folders from the
workspace. Previously without using packages, we assume that all
relevant query paths are already inside the workspace. With
packaging, this is no longer the case.
It is theoretically possible that there will be extra upgrade scripts
that are not on the resolved search path, but are included in the
workspace. This situation would have worked in the past.This is not a
situation that we expect to happen in practice. And if this does happen,
I believe this is an error and all upgrades should be added explicitly
to the search path.
An open question is if this will work with downgrade scripts. If it does
not, then I don't think this change makes things any worse than before.
The Actions VM image containing v2.7.6 of the CodeQL CLI has now fully
rolled out, so we no longer need to download the latest CodeQL bundle to
use this CLI and include this repo in the ML-powered queries beta.
This was our first temporary attempt at configuration of a remote
query run. I don't think that we're using it anymore, so it simplifies
the code to remove it.
Successfully completed queries will be stored on disk and available
across restarts.
- The query results are contained in global storage.
- Metadata and a summary about a query are stored in workspace storage.
- There is a job that runs every 2 hours to determine if any queries are
old enough to be deleted.
The goal with this change is to simplify the query history to make it
possible to serialize and de serialize.
This change adds serialization support. Since query history objects are
complex, the de-serialization requires manipulation of the
de serialized object prototypes.
Two small bugs:
1. The AST view command was viewing the wrong ast when the command was
selected from the context menu. It was always selecting the active
editor instead of the item selected in the file menu.
2. The `codeql.showLogs` command was not being registered properly.
With this change, there is uniform error handling, telemetry,
and disposal.