The remote queries tests were testing the data on the filesystem, rather
than the data submitted to the server. This required using a `dryRun`
parameter to prevent deleting the temporary directory, while we can
actually just test against the submitted data.
This will create an in-memory filesystem of the submitted query pack by
un-tar-gz'ing the query pack into memory and using that to test the
existence of certain files.
There is some common logic between remote queries and the variant
analysis flows which deals with parsing the query and asking the user
how to run the query. This extracts that part of the logic to a separate
method such that the only logic left in the actual `runRemoteQuery`
method is related to submitting the query.
This also changes the failure reason alert component to remove the logs
button since it's not used by any failure reason. Instead, a link is
added into the message for a failed Actions workflow using which the
Actions workflow run may be opened.
Shared by the AST viewer, jump to def, and find references
contextual queries.
This allows contextual queries to have their dependencies
resolved and be run whether the library pack is in the
workspace or in the package cache.
Clear the CLI server's pack cache before installing packs,
to avoid race conditions where the new lock file is not
detected during query running.
Adjust some helper methods.
If the library pack containing the AST query does not have
a lock file, it is likely to be in the package cache, not
a checkout of the CodeQL repo.
In this case, use `codeql pack resolve-dependencies`
to create a temporary lock file, and `codeql pack install`
to install the dependencies of this library pack.
This allows the CLI to resolve the library path and
dependencies for the AST query before running it.
We were not yet showing any errors when a result download had failed.
This adds a warning icon to any repositories for which the download has
failed and allow expanding the item to show an alert.
This will show a message for the failure reason in the variant analysis
view when the variant analysis has failed. There don't seem to be
designs for these alerts, but we will need to do a full design review of
the view at some point anyway, so I don't think the exact text is
important.
The variant analysis view was missing an alert when the variant
analysis was canceled. This adds it, and also adds a story for checking
what the view of a canceled variant analysis looks like.