Unfortunately, one of the tests we have for local queries doesn't seem
to be working for variant analyses. I'm not sure why it isn't
working, but I think it's better to get the rest of the integration
tests in and then figure out what's going on with that one.
When rehydrating remote queries, we were awaiting the monitoring
command. Since this command may take minutes to hours to complete, it
seems like this would block the extension from loading. This is the same
issue as in https://github.com/github/vscode-codeql/pull/1698, but for
remote queries instead of variant analyses.
This will hide the "Analyzed" panel when there are no scanned repos and
it's completely empty.
When all three panels are empty, this will also hide the search bar and
filters, and will skip rendering anything for the panels.
This adds a new filtering on SARIF code snippets for very large code
snippets (defined as 8MB or more). If less than 1% of such a snippet
is highlighted, it will not include the code snippet in the analysed
results, and it will thus not be shown in the UI.
This is to avoid very large SARIF files that can cause the extension
host to crash when the analysis results are send to the UI. I don't
think any of these snippets would ever be useful to show, so it should
be fine to just not include them.
The extension doesn't actually use anything regarding the language of
variant analyses, so this just updates some types.
The actual Swift support is done in the CLI, which is also used for
determining which languages are actually supported. So, the environment
variable is already used by the CLI for showing supported languages.
We were using two different implementations for opening the query file
and query text between the query history and the results view. This
moves the better implementation in the view to a command and uses these
commands for opening the query text/file in the query history and view.
This results in consistent error messages and behaviour between the two
different views.
This will add error handling to the retrieval of variant analyses in the
monitor by catching the error. It will show a warning to the user and
log it. Then, it will simply sleep for 5 seconds and try again.
I'm not sure if we want to show all of these errors to the user since
this can result in many warnings popping up if many variant analyses are
being monitored, but this is probably that the user should be made aware
of.
This will add a progress notification to exporting results to give users
feedback about what's happening.
Unfortunately, we need to change some things in how we handle the
actions on completion notifications since we want the progress
notification to disappear when that notification shows. This results in
us having to remove the `await` on the
`showInformationMessageWithAction` calls.
The Gist title in the result export didn't take into account the actual
number of exported repositories, it only used the scanned, unfiltered,
repositories in the variant analysis. This switches it to use the actual
exported repositories for determining the result and repository counts.
This is somewhat more complicated than we'd expect it to be since the
results are being read in async, so we need to switch the order of
operations and store some additional information for being able to
compute this information. However, this also makes the code somewhat
easier to understand since the summary file is now being created in only
1 location, rather than being split between a method and a for-loop.
When deserializing a webview, it could happen that a view was already
manually opened by the user before the webview was deserialized. This
would result in duplicate webview tabs, which is not supported by the
manager.
This will close the webview that is being deserialized and focus on the
existing view. This should ensure that we never have duplicate loaded
webview tabs. There could still be duplicate webview tabs if there are
non-deserialized tabs, but once it is opened it should be closed
automatically.
This will disable the export and copy buttons when no results would be
exported by executing the command. In contrast to the "normal" filtering
in the view, this will also take into account the checkboxes since those
are also used in the extension host.
