This will change the pure tests Mocha setup to actually use the
`tsconfig.json` located in the `test` directory. Before, it was using
the root-level `tsconfig.json`. To ensure we are still using mostly the
same settings, this will extend the `test/tsconfig.json` from the
root-level `tsconfig.json`.
This splits the mock GitHub API server class into two parts: one for the
interactive, VSCode parts and one for the non-VSCode parts. This allows
us to use the non-VSCode part in tests.
At the moment we create the results manager as a private property on the `VariantAnalysisManager`.
If we instead created it at the extension level and passed it to the `VariantAnalysisManager`, we would have more freedom to write unit tests for the `VariantAnalysisManager` without needing to reach into a private results manager property.
We had previously added a no-op placeholder for when we attempt
to remove a variant analysis from our query history.
This adds the implementation:
- removes the item from the query history
- cleans up any existing result files attached to the variant analysis
NB: The remote queries would store all their results in a single folder.
For variant analysis, we store results per repo. The folder names are build
using a cache key and are stored in `cachedResults`. The cache key is
built from the variant analysis id and the repo name.
In order to delete the results, we've had to pass in the full variant analysis
object to the manager and call `cacheResults.delete()` for each of its scanned
repos.
Co-authored-by: Charis Kyriakou <charisk@github.com>
Co-authored-by: Nora Scheuch <norascheuch@github.com>
msw doesn't seem to support binary responses because it decodes them to
a UTF-8 string. To work around that, we will do a separate fetch of the
file and save that.
When the mock GitHub API server setting was moved to the top-level, we
forgot the comamnds in the `package.json`. This updates the commands to
have the correct visibility.
See: https://github.com/github/vscode-codeql/pull/1643
This adds a linter for JSON scenario files which will validate the JSON
files in the scenarios directory against the TypeScript types. It will
convert the TypeScript types to JSON schema to simplify this process.
Unfortunately, this will not currently allow adding scenarios with
failing requests since the types do not allow this. Rather than removing
this validation, we should fix the types. This can be done in a follow-up
PR.
The command lint expects all command palette commands to have a common
prefix which these violated. So, I've moved them to being a scoped
command so we can have different lints.
If the workspace is restarted while databases are being loaded, this
change prevents any from being lost.
The bug was that each time a database was added when rehydrating a db
from persisted state on startup, the persisted db list
was being updated. Instead of updating the list each time we add a db,
on restart, instead update the persisted list only after all are added.
Note that we need to update the persisted list after reading it in since
the act of rehydrating a database _may_ change its persisted state.
For example, the primary language of the database may be initialized
if it was not able to be determined originally.
* Fix missing DIL for new query server
* Fix DIL error message when QLO was not expected.
* Update extensions/ql-vscode/src/run-queries-shared.ts
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
This adds a new class which will setup the MSW server to record requests,
save them to memory and save them to files when calling a separate save
method.
This adds a Storybook add-on that allows you to switch between VSCode
theme. It follows the pattern of the [outline](https://github.com/storybookjs/storybook/tree/v6.5.12/addons/outline/src)
and [backgrounds](https://github.com/storybookjs/storybook/tree/v6.5.12/addons/backgrounds)
add-ons.
Unfortunately, it doesn't apply the CSS to just the elements it should
be applied to, but globally to the complete preview. This is a limitation
of using CSS files rather than setting inline styles on the elements. We
might be able to resolve this in the future by extracting the CSS
variables from the CSS files, but this is somewhat more involved.
- Avoid Installing `xvfb` since it is already available.
- Ensure `supportsNewQueryServer()` takes the CLI version into account
- Always run the new query server tests on v2.11.1 and later
- Avoid printing directory contents in `run-remote-query-tests`
- Run tests with `--disable-workspace-trust` to avoid a non-fatal error
being thrown from the dialog service.
- Ensure the exit code of the extension host while running integration
tests is the exit code of the actual process. Otherwise, there is
a possibility that an error exit code is swallowed up and ignored.
- Remove a duplicate unhandledRejection handler.
- Handle Exit code 7 from windows. This appears to be a failure on
exiting and unrelated to the tests.
- Fix handling of configuration in tests:
1. It is not possible to update a configuration setting for internal
settings like `codeql.canary`.
2. On windows CI, updating configuration after global teardown. So,
on tests avoid resetting test configuration when tests are over.
Also, I tried to remove all those pesky errors in the logs like:
> [2094:1017/235357.424002:ERROR:bus.cc(398)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
I was following advice from here, but I can't get it working.
- https://github.com/microsoft/vscode-test/issues/127
- https://github.com/electron/electron/issues/31981
This adds a documented way to change the theme in Storybook from the
VSCode Dark+ theme to the VSCode Light+ theme. It requires multiple
changes to two files, but these are all quite simple and it has been
documented on the "Overview" page.
Previously we were only checking whether we're triggering the download
command in the extension.
Now we're mocking `autoDownloadVariantAnalysisResult` on the
variantAnalysisManager and checking that it's being called for all repos
that have available results.
Before we make any changes, let's extract some of the monitor code into
smaller methods.
Since we have test coverage, we're able to do this quite comfortably.
We added a `successful` property to serialized local queries. But, this
property does not exist on older serialized queries. This change ensures
older queries get a `successful` property when deserialized.
The threshold at which the bad join order detection reports a warning was previously hard-coded to 50. Initial feedback from internal QL developers suggests that this is too high, and should be configurable in any case. I've made it configurable via the `codeQL.logInsights.joinOrderWarningThreshold` setting, leaving the default at 50. Once we get more feedback about what a better default value is, I'll update the default.
This adds tests for the duration calculation and moves it down a
component to make this easier. Adding tests for the
`VariantAnalysisHeader` would require constructing a complete variant
analysis object, while this is now just a simple unit test.
This will add some new date fields that have been added in the API to
the variant analysis types and factories. They are stored as strings
since storing them as `Date` would make the types inconsistent if they
are serialized to JSON (`JSON.stringify` -> `JSON.parse` would result
in strings rather than dates).
The `text` property is already nested under `query`, so it's redundant
to prefix it with `query`. This also makes it consistent with the other
properties.
This will implement the final step of opening the query text. Inside
the webview, this will send the message to the extension host to open
the query text.
This will add a new text document content provider for showing variant
analyses. This is separate from the remote queries content provider
to allow this to evolve separately. It also retrieves the query text
from the manager rather than passing the text directly to prevent the
webview from opening a tab with arbitrary content.
See: 4c527a3573/extensions/ql-vscode/src/extension.ts (L1242-L1257)
This will add a new query text field to the variant analysis submission,
which will also propagate to the variant analysis itself. This will
allow us to show the query text on the variant analysis page.
This will register all settings for which a `Setting` instance is
created as settings which will be reset. This should make it less
error-prone to change settings in tests.
The `vscode-test` package was renamed to `@vscode/test-electron` in
December of last year. This commit updates the extension to use the new
package name.
The reason for this change is that the `vscode-test` package was
somewhat flaky in actually starting VSCode to run the tests from the
command line. The new package also has some bugfixes and other
improvements which would normally have been part of a new version of the
`vscode-test` package.
This makes it possible to open the query file in the editor when
clicking on the query filename.
This is a slightly different implementation from the remote queries
implementation. The remote queries implementation will send the file
path to open to the extension host, and the extension host will simply
open the given file path. If someone is able to inject JavaScript into
the webview, this would allow them to open an arbitrary file in VSCode.
By moving the file path logic to the extension host, we can ensure that
we only allow opening the actual query file.
* QueryServer: Add support for new query-server
* Add a new canary flag to enable new query server support
* Add evaluation results to query object
Ensures better backwards compatibility with legacy query objects.
* Fix query server command name
* Add log message for new query server
* Use only legacy results
Co-authored-by: alexet <alexet@semmle.com>
This will implement ebba9949a8
and d18e3dd40e
for the `Compare` and `RemoteQueries` views. These should not be
impacted in the same way as the `VariantAnalysis` view, but this will
make them consistent and more resilient to future changes.
This cleanup function would never be called in normal operation, but if
we do decide to add a dependency to this `useEffect`, this will ensure
that only one listener is registered at a time.
When the variant analysis view was being rerendered, we were also
reregistering the message listeners, while not deregistering the old
ones. This resulted in a loop of message listeners being registered,
and the variant analysis being rerendered every time a message was
received by one of the listeners. This will ensure that the listener
is only registered once to prevent this from happening.
To make debugging the view easier and prevent needing to run a variant
analysis for each change, this will add a simple command which opens a
variant analysis by its ID. This it not intended to be visible to users
at any point.
Now that we're unzipping results, we also have to use something closer
to a zip file when testing download functionality for the
`variantAnalysisManager`.
The `variantAnalysisManager` has access to the
`variantAnalysisResultsManager` so we could've stubbed the result
manager's `download` method instead of going as far as using a zip
fixture.
However, since the results manager is private it seems bad to make it
public in order to stub one of its methods.
So using realistic data in the setup seems like a good compromise.
This will:
- download a zip file as an ArrayBuffer
- save the file as `results.zip`
- unzip the contents into a `results/` folder
For the tests:
- In order to check whether we're saving the correct files in the tests,
we've had to make the `getRepoStorageDirectory` method public.
Unfortunately the temporary file path generated for tests is random so
we're not able to hardcode it.
- Now that we have a real zip file to use in our tests, we're first
converting this file into an ArrayBuffer, then stubbing the API to
return it. We then check that it's saved and unzipped correctly.
This matches what type of file we'd expect in real life: a zip file
containing a sarif file.
We've copied an example `results.sarif` file from other tests in the
`no-workspace` folder.
We expect this method to return a zip file which can be typed to an
`ArrayBuffer`. In the following commits we'll read this buffer and save it
as a zip file.
This class will be used to set test config values for the tests. It is
able to set the config value to a specified value for every test and
restore the value to the original value after the test.
Instead of using the `glob` library and a custom promise, this will use
`glob-promise` which is used by other parts of the codebase already.
This reduces the amount of code which manually needs to call `reject`
and makes it easier to read.
When we first submit the variant analysis for processing, we'd like to update
the query history panel.
At the moment we're just adding the setup for triggering the event. In a future
PR we'll consume this event and change the query history panel accordingly.
In order for this to happen we will need to introduce a new `VariantAnalysisHistoryItem`
type which will massage the data we get from the API into a type which the Query
History panel can consume.
Co-authored-by: Shati Patel <shati-patel@github.com>
When the `viewLoaded` message is received by the view, it will now
retrieve the variant analysis from the manager and send it to the
view. This will allow the view to display the variant analysis.
This will change tests that are using a mocked `CancellationTokenSource`
to use a real `CancellationTokenSource` instead. Tests are run inside
VSCode, so we can use these without mocking.
To create the interpreted and raw results from the SARIF/BQRS files, we
need some information from the repo task object. This will store the
repo task object to the filesystem as JSON so we can read them when
loading results.
In most cases, we will not have access to the full repo task object
since this needs to be retrieved from the API. Since we are only using
the full name from the repo task object, we can just use the full name
instead.
This will store all variant analysis that are run in the manager. Right
now, it only stores the variant analyses in memory. In the future, these
will be loaded from the query history and can be restored after a
restart.
We register a handler for the old command ID, but do not mention it in package.json.
This seems to be backward compatible without polluting the command palette.
This adds a new variant analysis results manager which is responsible
for downloading and loading variant analysis results to/from the
filesystem. It is essentially the `AnalysesResultsManager` modified to
suit the variant analysis results.
All fields in the variant analysis skipped repositories are optional,
but this was not properly defined in the API types. This will correct
the types and the functions processing the data such that they handle
non-existing fields.
To be able to send messages to the open view for a variant analysis, we
need to have a reference to the view. This is done by keeping track of
all open views in a dictionary indexed by their variant analysis ID.
We currently only allow one view per variant analysis, but do allow
multiple variant analysis views to be open at a time. In the future, we
may want to allow multiple views per variant analysis (such that e.g.
"Split right" works), but this is not supported yet.
The reason for the indirection through the interfaces is to prevent
circular dependencies between the variant analysis view and the manager.
This won't have an `id` field. We initially generated this the same
way we did for all other skipped repos, but this one is special because
it's only providing the fullName field, while the others also provide
`id` and `private`.
This introduces a new `autoDownloadVariantAnalysisResult` command which
will be called by the VariantAnalysisMonitor every time it detects a new
repo has been scanned.
In turn, this will use the `autoDownloadVariantAnalysisResult` method
which we defined in an earlier commit on the VariantAnalysisManager.
This method will be called from the VariantAnalysisMonitor once
a new repo has been scanned.
It will then perform an API request to get the repo task for it,
which will contain an `artifact_url`.
Finally it will use the API method we introduced in the previous commit
to download the result for the repo and then save it on disk.
In a previous PR [1] we introduced factories for generating variant analyses
(and their associated objects) that were returned from the API.
Let's also introduce factories for generating their VSCode equivalent.
We can immediately use them for generating a VariantAnalysis object for the
monitor tests.
[1]: https://github.com/github/vscode-codeql/pull/1545
This is a follow-up to clean up the skipped and analyzed repository
component duplication. The rows in both tabs are very similar, so this
will combine them to use a single component.
This will open the variant analysis view after the variant analysis has
been submitted. It will also show a notification that the analysis has
been submitted, which includes the query name.
This implements persistence for the variant analysis webview, allowing
the webview panel to be restored when VSCode is restarted. It's probably
easier to add this now than to try to add it later.
The basic idea is that there are no real differences when opening the
webview for the first time. However, when VSCode is restarted it will
use the `VariantAnalysisViewSerializer` to restore the webview panel.
In our case this means recreating the `VariantAnalysisView`.
To fully test this, I've also added a mock variant analysis ID as the
state of the webview. This value is now randomly generated when calling
the `codeQL.mockVariantAnalysisView` command. This allows us to test
opening multiple webviews and that the webviews are restored with the
correct state.
See: https://code.visualstudio.com/api/extension-guides/webview#persistence
At the moment we're only able to send one of:
- repositories
- repositoryLists
- repositoryOwners
In the future, we intend to be able to send a combination of these
but at the moment the API will only ever allow you to send one.
So let's be consistent and just send `repositories` here.
Currently, when running a query which produces raw results, we will show
all repositories, even if they do not have any results. This change will
ensure that we are only showing repositories which have results. This
matches the behavior for queries which produce interpreted results.
The `controllerRepo` parameter was being encoded/escaped by Octokit,
resulting in a URL like
`repos/dsp-testing%2Fqc-controller/code-scanning/codeql/queries` rather
than `repos/dsp-testing/qc-controller/code-scanning/codeql/queries`.
This switches it to use the ID instead, since we already have the ID
and do not have access to the owner and repo separately anymore.
Now that we have a monitor, we expect the variant analysis to return
a list of scanned repos.
Let's re-use our previous factory for creating mocked responses to
get a dummy variant analysis with scanned repos.
In a previous commit we were submitting a variant analysis to the API
and then triggering a `monitorVariantAnalysis` command.
Here we're hooking up the command to the VariantAnalysisMonitor class.
This will poll the API every 5 seconds for changes to the variant
analysis. By default it will continue to run for a maximum of 2 days,
or when the user closes VSCode.
The monitor will receive a variantAnalysis summary from the API that
will contain an up-to-date list of scanned repos.
The monitor will then return a list of scanned repo ids.
In a future PR we'll add the functionality to:
- update the UI for in progress/completed states
- raise error on timeout
- download the results
So that we're able to:
- set the status value
- build scanned and skipped repos by default
For previous tests, we needed to perform checks on scanned & skipped
repos so we needed to build them outside of this method. When we re-use
this method for the VariantAnalysisMonitor, we will just need a generic
ApiResponse so we can create these repos inside the method.
We're going to need some of these methods to generate a valid VariantAnalysis.
We might as well extract them from the tests for the VariantAnalysisProcessor.
Once we submit a variant analysis and get our response from the API,
we'd like to set up a way to monitor the variant analysis as it starts
producing live results.
Here we're using a VSCode command to trigger a monitoring process which
will poll the API for changes.
The `RawResultsTable` was using inline styles, while we should prefer
to use styled components. This refactors it to use styled components and
also improves some other miscelleanous things (extracting the props to
a separate type and moving the `Cell` above the `Row` since the latter
uses the former).
This adds the analyzed repositories component for showing within the
"Analyzed" tab. I wasn't completely sure whether there should be a
difference between "Pending" and "In progress", but pending will now not
show an icon, while in progress will show a spinner.
For the collapsible items, it does not reuse the `CollapsibleItem`
component because that component is tightly coupled with the styles
of the remote queries component.
This creates the component for showing the outcome panels. It does not
implement the content of each individual panel; it only implements the
tabs, panel views, and the general warnings.
I came across this when I had a query that threw an error while running
for unrelated reasons. At this point, the query results were in a bad
state, but this caused `safeMax` to be called with `undefined` and
it prevented the extension from starting. This changed fixed the error.
This involved changing a few different methods to take a Repository object
instead of taking owner and repo separately. Overall I think this is a good change.
This will add Storybook stories for the error, success, and warning
icons, as well as for the generic `Codicon` component.
To show the available icons for the `Codicon` component, a static JSON
list is generated from the contents of a CSV file included as part of
the `@vscode/codicons` npm package. The command to regenerate the file
is included in the story.
This will change the VariantAnalysisHeader to take the VariantAnalysis
domain model instead of a large amount of props.
It also adds the `canceled` status to the `VariantAnalysisStatus` to
represent a stopped variant analysis.
The "Export All" button was always exporting the selected query, while a
different query could be open in a VSCode panel. This will ensure that
the query ID is passed to the export function, so that the correct query
is exported.
This refactors the CodePaths and FileCodeSnippet components to be more
readable and in style with the rest of the "new" components. It does the
following:
- Remove uses of the `style` and `sx` props; replace it by using
`styled-components` instead
- Remove uses of Primer icons
- Split out the components into multiple files
- Change the colors of the severity to match VSCode colors (and make
them themable)
I haven't removed the use of the Primer `Overlay` component yet, since
this component seems to do quite a lot and the VSCode WebView UI Toolkit
doesn't have a replacement for it.
The `runUpgrade` query server command is mistakenly caching the old
dbscheme in memory after running the upgrade. The problem is in the
CLI. The workaround is to restart the query server after running an
upgrade. This is not a great solution, but considering that explicit
upgrades are now very rare. I do not think it is worth putting in
too much effort for a proper fix.
The working directory of ESLint was not set directly, so ESLint warnings
did not show up in VSCode. This sets the working directory properly such
that ESLint warnings are shown in VSCode.
See: https://github.com/Microsoft/vscode-eslint#settings-options
This will make a distinction between cancelled local and remote results,
allowing us to hide the *Open Variant Analysis on GitHub* item from
local failed/cancelled items. It also hides the *Show Evaluator Log*
items for cancelled/failed remote queries.
This sets up Storybook for testing of React components. It adds stories
for some of the MRVA components. It does not add stories for the main
MRVA views since those are not independent of VSCode and need to be run
from within VSCode.
It seems like the result-index artifact may not be available immediately
after the workflow run has finished. This adds a retry mechanism to wait
for the result-index to be available. It will retry at most 10 times
with a wait of 1 second between each retry.
The original code that logged the human-readable log summary generated the log asynchronously, which was a reasonable choice. When I added support for viewing and scanning logs, I didn't notice that the summary was being generated asynchronously, and wrote my code assuming that the summary was already on disk when I opened it to find where each relation's log started. The effect was that, depending on timing, the evaluation sometimes failed with an error popup complaining about not being able to open the log summary file.
The fix is to _generate_ the log summary synchronously, but continue to _log_ it asynchronously.
This does not remove the previously added mechanism of not requesting
credentials, but using them when they are available. I expect this to be
used in the future.
This makes authentication for download GitHub CodeQL databases optional.
If you are already authenticated, your token will be used. If you are
not authenticated, an anonymous request will be made.
If the canary flag is enabled, you will be prompted for credentials when
downloading a database and you are not yet logged in.
This will include the Codicons inside the webview bundle, reducing the
number of files that need to be loaded and the resource roots that need
to be included.
This will add a new abstract class that implements the creation of the
panel and webview to reduce duplication across the different interface
managers.
This will move all webviews into a single Webpack bundle. This will make
it easier to add new webviews since we don't need to add a new bundle,
but just need to add a new directory with an `index.tsx` file.
It also moves the CSS processing to Webpack so that we don't need to
specify the CSS files to use separately, but can simply do so in the
TypeScript files.
When the MRVA results panel is closed (so the panel gets disposed) and
opened again, it would not load the MRVA data (such as whether a query
has already been downloaded). This fixes it by also resetting the
internal state of whether the panel is loaded when the panel is
disposed.
We'd like to remove duplicate whitespace in these labels in order
to make it less likely that we introduce extra space.
We initially also tried trimming whitespaces at the start and end
of these labels but that had no effect.
We'd like to be able to add tests for when the result count exists and
when it's missing.
Let's change the createMockRemoteQueryInfo method so that we can pass
in parameters by name, e.g.
```
createMockRemoteQueryInfo(undefined, 2)
```
becomes
```
createMockRemoteQueryInfo({ repositoryCount: 2 }
```
We were splitting JSONL records based on the current OS newline sequence. In order to handle reading of logs from the opposite OS, I've switched our split to handle both flavors of line ending. This originally showed up as log parser unit tests failing on Windows (the checked-in log used Unix line endings), but could affect real world usage as well.
`undefined`, `null` and 0 will evaluate to `false` so if we only want to
display the repository count when these values are not present we can
check for a truthy value:
```
query.repositoryCount ? `(${pluralize(...)})` : '';
```
instead of checking explicitly:
```
query.repositoryCount !== undefined && query.repositoryCount !== null && query.repositoryCount != 0 ? `(${pluralize(...)})` : '';
```
We were splitting JSONL records based on the current OS newline sequence. In order to handle reading of logs from the opposite OS, I've switched our split to handle both flavors of line ending. This originally showed up as log parser unit tests failing on Windows (the checked-in log used Unix line endings), but could affect real world usage as well.
When a queryResult is created, it comes with an array for AnalysisSummaries.
There is one summary per repository.
We've had to calculate the total number of results for all summaries in multiple
places, so let's extract a method for this as well.
There are at least 4 different files where this method could DRY things up,
so let's extract it.
I've chosen to move it to src/helpers.ts but happy to be told there's a better
place for shared utility methods like this one.
Previously we would set all remote query results to -1 when someone
attempted to sort queries.
We would then only sort local queries as those had access to the number
of results.
Let's include number of results for remote queries in the sorting.
Co-authored-by: Shati Patel <shati-patel@github.com>
In the previous commit we're now displaying number of results for remote
queries.
Previously we could only do this for local queries.
Let's make the format match for both types of queries by displaying
number of results in parentheses: `(x results)`.
Co-authored-by: Shati Patel <shati-patel@github.com>
When you run a remote query, we'd like to display more information about
it in the Query History panel.
At the moment we've improved this [1] by adding the language and number of repositories.
In this commit we're also adding the number of results for a remote query.
So the final format of the query history item will change from:
`<query_name> - <query_status>`
to
`<query_name> (<language>) on x repositories (y results) - <query_status>`
[1]: https://github.com/github/vscode-codeql/pull/1427
Co-authored-by: Charis Kyriakou <charisk@github.com>
Co-authored-by: Shati Patel <shati-patel@github.com>
While we're here we're also adding a test for the `exportResultsToGist`
method, as there were no tests for the `export-results.ts` file.
We initially attempted to add the test to the pure-tests folder, but the
`export-results.ts` file imports some components from `vscode`, which
meant we needed to set up the test in an environment where VSCode
dependencies are available.
We chose to add the test to `vscode-tests/no-workspace` for convenience,
as there are already other unit tests there.
We've also had to import our own query and analysis result to be able
to work with data closer to reality for exported results.
Since we've introduced functionality to build a gist title, let's check
that the `exportResultsToGist` method will forward the correct title to
the GitHub Actions API.
Co-authored-by: Shati Patel <shati-patel@github.com>
We'd like to re-use this to test the `exportResultsToGist` method in
`export-results.ts`.
So let's move it to a shared folder in the `vscode-tests/no-workspace` folder.
Since there's no `helper.ts` file in this folder and to avoid any confusion with
the `helpers.test.ts` file, I've opted to put this shared method into `index.ts`.
Happy to be told there's a better pattern for this as it doesn't feel very nice!
Let's handle this case gracefully and skip displaying the number of repositories
when they're not available.
Similarly let's add a check to see if we should pluralize the `repository` noun
or not.
Co-authored-by: Shati Patel <shati-patel@github.com>
All exported MRVA gists are given the name `CodeQL variant analysis
results', which makes it hard to work out what it contains at a glance.
We're adding more information in the gist title to make it more useful.
Example of new title:
`Empty Block (Go) x results (y repositories)`
This translates to:
`<query name> (<query language>) <number of results> results (<number of repositories> repositories)`
Co-authored-by: Shati Patel <shati-patel@github.com>
We'd like to improve MRVA query gists by giving them more descriptive
titles that contain useful information about the query.
Let's add the number of query results to the title of the gist.
To do this we'll first need to count all the results provided to us in
the `analysisResults` array. There is an item in this array for each of
the repositories we've queried, so we're introducing a method to sum up
results for all the items in the array.
Co-authored-by: Shati Patel <shati-patel@github.com>
Previously, there was a bug where quick eval queries would crash when
the eval snippet is in a library file.
The problem was that the `codeql resolve queries` command fails when
passed a library file. The fix is to avoid passing the library file at
all. Instead, pass the directory. This is safe because the resolve
queries command only needs to know which query pack the file is
contained in. Passing in the parent directory is the same as passing in
a file in this particular case.
Currently `resolve ml-models` only supports queryspecs, i.e. .ql, .qls,
directory, and query pack specifications. Therefore quick evaluation within
a library isn't
supported.
In order to run our cli-integration tests, we're required to have a
local copy of the codeql CLI repo. We can then run the tests by running
the `Launch Integration Tests - With CLI` task from inside VS Code.
(See CONTRIBUTING.md for details.)
If we don't have the CLI repo cloned locally or we're not pointing to it
in `launch.json`, we don't get a clear indication of what the problem is.
The tests will still attempt to run.
Let's fail fast instead and add an actionable error message to the output.
The controller repo is set via the `codeQL.variantAnalysis.controllerRepo`
setting in VSCode.
While we have validation to check that the repo is not null and the
format of the controller repo is correct: `<owner>/<repo>`, we still
allow you to provide a non-existent repo (e.g. a mispelled one).
When the MRVA request is sent over to the API, it will verify that the
repo exists and return a very generic "Not Found" response.
This will then be logged out in the "Output" tab for VSCode.
We'd like to give users a better indication of what has gone wrong in
this case so we're making the error message more verbose.
Co-authored-by: Charis Kyriakou <charisk@github.com>
Co-authored-by: Shati Patel <shati-patel@github.com>
How did this ever work? It was using an old variant of the
qlpack name.
Also, this commit makes the unhandledRejection handler less
verbose. This gets hit when the tests end and there is a cancellation.
this is not an error.
For an inexplicable reason, the first time the selection
occurs, the value is incorrect. We often miss this error
in our tests if the expectation is reached before the
selection changed event fires.
It seems that the _second_ time the selection changed
event fires, the value is correct.
This change ensures we wait for the second selection change.
And we avoid running expectations until then.e
We're upgrading the minimum version of webpack from 5.28.0 to 5.62.2
since this version doesn't rely on OpenSSL for its hashing algorithm so
it wouldn't need legacy OpenSSL support when we decide to upgrade to
Node 18.
This allows us to build our extension on Node 18:
https://github.com/github/vscode-codeql/runs/6904100934?check_suite_focus=true
Happily, this also works fine with our current version of Node (16.13.0).
Adding two things:
- A bit more detail on how to add a tag and how to delete a badly named one
- Switch to the official way of sharing tags according to the git docs[^1]
[^1]: https://git-scm.com/book/en/v2/Git-Basics-Tagging
It's been pointed out that MRVA results are hard to read as the font is
small and narrowly spaced. It also doesn't match the font type normally
used in source files.
We can instead switch to using the font-family used by VS Code itself and
increase the font size from `x-small` to `small` for code snippets.
As recommended here https://github.com/github/vscode-codeql/pull/1369#issuecomment-1142418037, we want to stay in sync with the current node version shipped with
VSCode (v16.13.0):
32d40cf44e/remote/.yarnrc (L2)
For this we can add a `.nvmrc` file to alert nvm to switch to the preferred version automatically.
It will also help prevent builds from failing when setting up the project for the first time, as building the extension currently fails in Node v18: https://github.com/github/vscode-codeql/issues/1373
We're also updating the docs to mention using `nvm` to manage node versions and point to the right place to check for current supported versions.
1. `exportCsvResults` now no longer requires an `onFinish` callback.
2. The test adds a generic framework for creating a mock cli server.
This should be used in future tests.
If the `#select` resultset doesn't exist, arbitrarily choose the first
result set when viewing csv results. This will almost certainly be the
correct result set.
In the future, we could offer a popup if there are multiple result sets
available, but let's wait on that until someone actually asks for it.
Create the `time.ts` module as a place to put fime functions.
Move two time functions there and create tests for them.
The `humanizeUnit` function now uses ECMAscript apis. This ensures
that pluralization happens appropriately.
Also, fix a small bug in the results view to enure `repository`
is correctly pluralized.
The `lastUpdated` value is now the duration between timestamp of the
last time the repo was updated and time the file was downloaded.
This fixes the duration and it won't change over time.
1. Refactor references of `Stargazers` to `RepositoryMetadata` since
the query is now more generic.
2. Update the graphql query to request last updated as well as stars
3. Update web view to display last updated
4. Update sort mechanism for last updated
A few notes:
1. I used `Intl.RelativeTimeFormat` to humanize the times. It wasn't as
simple as I had hoped since I need to also make a guess as to which
unit to use.
2. The icon used by last updated is not quite what is in the wireframes.
But, I wanted to stick with primer icons and I used the closest I can
get.
3. The last updated time is retrieved when the query is first loaded
into vscode and then never changes. However, this time is always
compared with `Date.now()`. So, opening the query up a week from now,
all of the last updated times would be one week older (even if the
repository has been updated since then).
I don't want to re-retrieve the last updated time each time we open
the query, so this timestamp will get out of date eventually.
Is this confusing as it is?
The new support will be available in the next
release of the CLI, most likely 2.9.3,
This change requires the query to be run to be
passed in to the call to resolve ml-models.
The main problem this commit fixes is with vscode 1.67.0, an error is
thrown when inside of integration tests and a dialog box is opened. We
were opening the telemetry dialog box. Now, an env variable is set
during cli-integration tests that prevents the dialog from being
opened.
There are also other cleanups and improvements with cli-integration
tests that assist with running locally:
- `vscode-test` dependency has been renamed to `@vscode/test-electron`,
so use that instead and make the small API changes to support it.
- Commit the codeql-pack.lock.yml file so it isn't recreated on each
test run.
- Ensure all databases are removed before _and after_ each test run
that manipulates the set of installed databases
- Similarly, for quick query files, delete them before and after each
test.
- Change some async `forEach` blocks to for loops in order to support
sequential operations more easily.
This dependency was only used to parse package.json and
this can be just as easily parsed by regular JSON object.
jsonc can also parse JSON with comments, but there are no
comments in package.json.
This fixes a bug where an open results view will accumulate results from
other queries who have their results downloaded while this view is open.
The fix is to ensure that the results view for the query is open when
some results are downloaded.
This will now name databases downloaded from github based on their nwo.
Also, this adds a new button to suggest downloading from github in an
empty databases view.
Two scenarios handled:
1. no database for existing repo
2. repo does not exits (or no access rights for current user)
In either case, an error message is sent to the logs, with a notificaiton
in a popup.
Also, change interpolation of result count. For Remote queries, this
value will be empty. For local queries, use the label `X results`, where
`X` is the number of results for this query.
The labels for remote query items are interpolated using the same
strategy as local queries with two caveats:
1. There is no easy way to get the result count without reading files,
so, this value is kept empty.
2. There is no database name for remote queries. Instead, use the
nwo of the controller repo.
Also, adds tests for the history item label provider.
The label provider is the instance that performs the logic for
generating labels for history items, using string interpolation when
necessary.
This commit creates the label provider and uses it with local queries.
Remote queries will be changed in the next commit.
(Only in recently introduced locations. More work still needs to be
done.)
Also:
- Change error to info
- Create credentials directly, don't use a callback.
This change issues a cancel request when the user clicks on "cancel" for
a remote query.
The cancel can take quite a while to complete, so a message is popped up
to let the user know.
The labels for remote query items are interpolated using the same
strategy as local queries with two caveats:
1. There is no easy way to get the result count without reading files,
so, this value is kept empty.
2. There is no database name for remote queries. Instead, use the
nwo of the controller repo.
The extension ms-vscode.test-adapter-converter is now available on
open-vsx, but under a different name.
Fixes https://github.com/github/vscode-codeql/issues/1085
I have verified that I can publish and install the extension by
manually publishing v1.6.4.
1. Source map support means that stack traces will point to the *.ts
file instead of the generated *.js file
2. Cleaning test dependencies means moving all mocha and chai
registration into the respective index files and removing unnecessary
imports.
Now, when running `npm run watch`, both the regular tsc command
and the webpack command will be run in watch mode.
The raw gulp tasks are now:
- `gulp watchView` to watch webpack compilation.
- `gulp watchCss` to watch for css changes.
- `gulp compileView` to compile the webpack once and exit.
However, stats are no longer being printed out. Not sure why.
Before displaying any results for a remote query, ensure that all
downloaded results are in memory. This ensures the proper download icon
is displayed alongside each NWO.
Also, fix two smaller issues:
- Ensure the `Open Query Directory` command opens inside the specified
directory.
- Ensure label changes are saved across restarts.
The default version of tsc in vscode is now 4.5.4. This version
has changed the type of the variable in the catch block.
Previously, it was `any`. Now it is `unknown`.
This change updates vscode so that it can build with 4.5.4.
Previously, this had been a bit of a pain since sometimes running
a compile task in vscode will use the global default version of
tsc.
This fixes a bug where the ast viewer was not updating its source
location when a user clicks on different parts of a file.
The problem was that the file name of the AST viewer was being stored as
a base name, which was getting compared with the full URI string of the
current file.
This fixes the comparison to ensure that the full URI strings are always
being compared.
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
This commit deprecates the the cutsom log directory option by saving
all log files with query history.
There is a simplification of the `OutputChannelLogger` since it no
longer needs to manage deleting log files on exit.
Also, the `codeQL.runningQueries.customLogDirectory` is marked as
deprecated. If this value is being used, a warning message is popped
up after the query completes.
Without these changes, a race condition was sometimes hit when viewing
a graph. There are two, related issues that are fixed. These problems
did not appear in the past since rendering a normal results view is
much faster and the message handler is always already set up by the
time the interface first sends a message over to the web view.
1. `vscode.postMessage({ t: 'resultViewLoaded' });` was being called
before the component is completely mounted. Ie- `componentDidMount`
is not called. So, the interface is notified that the web view is
ready to receive messages _before_ it is actually ready to receive
messages.
The change ensures the interface only sends messages when the web
view is ready.
2. `this._panelLoaded` is never set to false if the panel is unloaded.
This means that if a panel is re-opened, the interface assumes that
the view is nearly _immediately_ ready to receive messages.
The change ensures that the interface waits for the webview to really
be loaded before sending messages.
In both of these cases, if the interface sends the `setState` message
too early, then the message is ignored since no handlers have been added
to the web view.
Do this by actually walking the interpretation directory.
Move the directory walker from tests to prod and make it async. Also
add tests for it.
And add a warning on graph views to let users know that it is not
production quality.
Finally, change the interpreted directory to be `graphResults` instead
of `interpretedResults.sarif`.
Adds structured evaluator logging on a per-query instance to CLI v 2.8.2+. The newline-delimited JSON logs are emitted to `structured-evaluator-log.json` in the directory with other query artifacts, but not consumed by the extension.
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
Adds some tests for reading in the history and manipulating.
There are some more tests to come later. Maybe in another PR, maybe in
this one.
Note that this PR uses a new node 16 API String.prototype.replaceAll.
I think this is ok since vscode ships with node 16. If this causes
problems, I can separate to a different PR and we can discuss there.
Since we are now storing query history on disk, we will need to handle
situations where versions change. For now, there is only version 1. In
the future, we may need to make breaking changes to this format and we
need the flexibility to detect and possibly handle different versions.
In this case, users don't often downgrade their vscode versions, so
most likely, we only need to be forward compatible. Ie- we need to
handle moving from v1 to v2, but not the other way around.
This commit adds a check if a results artifact already exists before
trying to download it again.
This is not a complete solution since the page icon will still have a
download button even if the artifact already exists. In this case,
clicking on it will avoid downloading it a second time.
The next step is to read in the downloaded artifacts and display them
appropriately.
Remote query items will be stored in query history and will remain
available across restarts.
When the extension is restarted, any `InProgress` remote queries will
be monitored until they complete.
When clicked on, a remote query is opened and its results can be
downloaded. The query text and the query file can be opened from the
history menu. A remote query can be deleted as well, which will purge
all results from global storage.
Limitations:
1. Labels are not editable
2. Running multiple queries that each run on the same repository
will have conflicting results and there will be errors when trying
to view the results of the second query. This limitation is not new,
but it is easier to hit now. See #1089.
Both of these limitations will be addressed in future PRs.
Because errors when running queries tend to have better explanations
in the query server log instead of the extension log, by default open
the query server log for query errors.
This is another incremental step on the way to saving history.
This commit adds remote items to the history view. It adds in progress
and completed icons. Users can explicitly remove items.
Here is what is _not_ working:
1. Any other query history commands like open results or open query.
2. Seeing items after a restart.
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 is a step on the way towards storing remote query history across
restarts.
This PR adds a `QueryHistoryInfo` type that is a union of two types:
`LocalQueryInfo` and `RemoteQueryInfo`.
`LocalQueryInfo` used to be called `FullQueryInfo` and `RemoteQueryInfo`
is only a skeleton right now. The body will be added later. This PR
only introduces it and changes types to make future PRs simpler.
Also, `slurp` and `splat` have been moved to the `query-serialization.ts`
module.
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
The viewer is largely implemented now with the following features and
limitations:
1. Any query with `@kind graph` will be opened as a graph
2. Queries that are `@kind graph` and
`@tags ide-contextual-queries/print-cfg` will be used in the
`CodeQL: View CFG` context command. This will be visible
similar to how the AST viewer works. If there is not exactly
1 such query for a given language, then the extension will throw
an error.
3. Unfortunately, the cg viewer assumes that the entire file will
be added to the graph, so often this will be too big, That leads to
the following limitation:
4. There is no size checking on the graph. Graphs that are too big will
crash vscode.
5. Lastly, there is a small bug in how the `@id` is interpreted. Any
`@id` with a `/` in it will place the `.dot` in a location that
can't be found by vscode. So, just don't name your queries with any
`/`.
This feature is only available in canary mode.
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.
Fixes a bug where quick eval was showing empty query text.
Previously, `getQueryText` was looking up the query text when it was
called if the specified text was empty. This was removed with the
recent changes to query history. It was also a bug since the query file
could have changed after the query was run.
This change ensures that if the quick eval position is empty, the
entire line is returned as the quick eval location.
This commit fixes two related issues with the
history view.
1. Sort order was changing after a query item completed. The fix is a
change in how we fire off the `onDidChangeTreeData` event. When the
event is fired with a single item, that item is pushed to the top of
the list. I'm not exactly sure why this wasn't happening before, but
I suspect it was because we were refreshing the list at the same time
as we were inserting the new item.
The solution here is to always refresh the entire list, instead of
single items. This is fine since re building the list is a trivial
operation. See the `refreshTreeView()` method.
With this change, the sort order is now stable.
2. Originally reported here: #1093
The problem is that the internal treeView selection was not being
updated when a new item was being added. Due to some oddities with
the way selection works in the tree view (ie- the visible selection
does not always match the internal selection).
The solution is to use the current item from the `treeDataProvider`
in `determineSelection`.
Also, this change makes the sorting more precise and fixes some typos.
This is a large commit and includes all the changes to add query
history items immediately. This also includes some smaller related
changes that were hit while cleaning this area up.
The major part of this change is a refactoring of what we store in
the query history list. Previously, the `CompletedQuery` was stored.
Previously, objects of this type include all information about a query that was run
including:
- Its source file and text range (if a quick eval)
- Its database
- Its label
- The query results itself
- Metrics about the query run
- Metadata about the query itself
Now, the item stored is called a `FullQueryInfo`, which has two
properties:
- InitialQueryInfo: all the data about the query that we know _before_
the query completes, eg- its source file and text range, database, and
label
- CompletedQueryInfo: all the data about the query that we can only
learn _after_ the query completes. This is an optional property.
There is also a `failureReason` property, which is an optional string
describing why the query failed.
There is also a `FullCompletedQueryInfo` type, which only exists to
help with stronger typing. It is a `FullQueryInfo` with a non-optional
`CompletedQueryInfo`.
Most of the changes are around changing how the query history accesses
its history list.
There are some other smaller changes included here:
- New icon for completed query (previously, completed queries had no
icons).
- New spinning icon for in progress queries.
- Better error handling in the logger to handle log messages when the
extension is shutting down. This mostly helps clean up the output
during tests.
- Add more disposables to subscriptions to be disposed of when the
extension shuts down.
* Be nicer about where to open the results webview
Currently, the webview _always_ opens next to the currently active
editor. This is a pain if you already have 2 columns open since this
means that the webview will open in a third column, which is rarely
what you want.
This change uses a more sophisticated approach to opening the webview:
1. If there is only one column, open webview to the right of it
2. If there are multiple columns and the active editor is _not_ the
last column, open to the right of the active editor
3. Otherwise open in the first column.
This will avoid opening a new column unless there is only one column
open right now.
There is no native API that vscode exposed to compare column locations,
so this uses the `ViewColumn` api is a slightly non-standard way.
A limitation is that if the last column is empty and the active editor
is to the left of it, then the webview will not be opened there (which
would be nice). Instead, it will be opened in column 1.
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
* Add code lens for quick eval command
* Ensure commented out predicates do not have code lens
* Improve conditional check for commented out predicate detection
* Refactor regex
* Move comment check to eliminate evaluating regex more than once
Co-authored-by: marcnjaramillo <mnj.webdeveloper@gmail.com>
This is in preparation of supporting structured query logs.
When passing this option, use the old format of query logs.
Later, when we want to add support for structured query
logs, we can add remove this option.
1. Acknowledge that the CLI has a bug for path serialization on <=2.7.2.
Avoid testing the query path on that version.
2. Fix calculation of root path on windows.
This change allows remote queries to run a query from a directory that
is not in the root of the qlpack.
The change is the following:
1. walk up the directory hierarchy to check for a non-local qlpack.yml
2. Copy over the files as before, but keep track of the relative
location of the query compared to the location of the qlpack.yml.
3. Change the defaultSuite of the qlpack.yml so that _only_ this query
is run as part of the default query.
Also, this adds a new integration test to ensure the nested query is
packaged appropriately.
* Add leniency in how positions are handled
Previously, positions with end column of 0 were rejected by the
extension. CodeQL positions are supposed to be 1-based, but the CLI
does handle 0-based and negative positions by using character offsets
from the current line start.
Instead of rejecting these kinds of positions, the extension should
handle them as gracefully as possible.
Fixes#999
* Update package lock
* Add leniency in how positions are handled
Previously, positions with end column of 0 were rejected by the
extension. CodeQL positions are supposed to be 1-based, but the CLI
does handle 0-based and negative positions by using character offsets
from the current line start.
Instead of rejecting these kinds of positions, the extension should
handle them as gracefully as possible.
Fixes#999
* Add changelog entry
When the extension loads a sorted result set, it takes a shortcut and
avoids loads a file with only the bqrs results for that sorted table.
However, it does not load the results for any other table. This causes
result set names to go away. This change ensures that if we are loading
a sorted table, we also load the result set names for all other tables
in that query.
Fixes#1005.
Now that the queries endpoint returns the id we can link straight
there. We'll make more changes to the progress tracking, but I think
it's worth making this minimal change now.
This is still a bit rough, but handles two cases:
1. There is a qlpack.yml or codeql-pack.yml file in the same directory
as the query to run remotely. In this case, run `codeql pack
packlist` to determine what files to include (and also always include
the lock file and the query itself. Copy to a temp folder and run
`pack install`, then `pack bundle`. Finally upload.
2. There is no qlpack in the current directory. Just copy the single
file to the temp folder and generate a synthetic qlpack before
installing, bundling and uploading.
Two cases that are not handled:
1. The query file is part of a workspace. Peer dependencies will not be
found.
2. The query file and its qlpack file are not in the same directory.
These should be possible to handle later. Also, need to create some
unit and integration tests for this.
* Add progress messages to LGTM download option.
* Add additional argument to get test passing again.
* Make edits requested by @aeisenerg
* Fix assertion in test case
* Update extensions/ql-vscode/CHANGELOG.md
The previous synthetic query suite was not finding the ast query because
the `qlpack` directive in a query suite only matches queries from the
default suite, which `printAST.ql` is not part of.
This changes to using `from` and `queries` directives.
Also, adds an integration test to ensure we find the queries using
different CLIs. However, this only tests using the latest `main` from
the codeql repository. I wonder if we should start testing using
different versions of the repo.
Most of the languages have recently been refactored into separate library and query packs, with the contextual queries defined in the query pack. In the near future, these contextual queries will move to the library pack.
Current CLI releases throw an error in `codeql resolve queries` when the extension tries to search the library pack for contextual queries. This change makes two related fixes:
1. If the queries are not found in the library pack, it then scans the corresponding standard query pack as a fallback.
2. It detects the problematic combination of CLI and packs, and avoids scanning the library pack at all in those cases. If no queries are found in the problematic scenario, the error message instructs the user to upgrade to the latest CLI version, instead of claiming that the language simply doesn't support the contextual queries yet.
This change depends on CLI 2.6.1, which is being released soon, adding the `--allow-library-packs` option to `codeql resolve queries`. That PR is already open against the CLI.
Updates the package dependencies to avoid dependabot errors.
I updated the `@types/gulp` to avoid some typings errors that were
introduced by incompatible versions of `@types/undertaker`.
Also, I forced resolution on `"glob-parent": "~6.0.0"` that avoids
a vulnerability on earlier versions.
I did a smoke test of features that use glob, as well as running a few
queries. All looks good.
Currently QLTestAdapter.run() calculates the databases affected by a set of
tests (those databases will be deleted and then reopened after test completion)
using a nested filter-find expression. Which does not work because the
predicate is an async function, so the expression is testing the truthiness of
a Promise instead of the async result.
This commit fixes the problem by implementing the same check with a loop so
that we can invoke the async predicate using await.
Currently, the token we use to create these PRs doesn't have sufficient permissions to set off PR checks. Maybe if we create the PR as a draft and have a real person mark the PR as "ready-for-review", this will be enough to start PR checks.
Add the `@typescript-eslint/no-floating-promises` rule with an allowance
for floating promises if `void` is used.
This increases safety and ensures that we are explicit when we avoid
awaiting a promise. I already caught a few bugish locations.
In general, we don't need to await the results of logging calls.
databases-ui, we were using a deprecated method for removing a
directory. `fs.rmdir` instead of `fs.remove`.
To deal with the problem of CodeQL tests modifying open testproj databases,
this commit removes open databases from the extension prior to running tests,
and tries to open those databases again after tests finish running.
This commit switches to the bleeding edge, main branch of the
codeql action. This helps us test the action before merging all
of the new changes into main, which occurs roughly once a week.
If there are commits that introduce bugs in codeql-action, then
we will be more likely to catch it before releasing to the world
if we are using it in this extension.
This ensures that directories renamed, added or deleted are
properly checked to see if they contain tests. The test tree
will be correctly updated when any directory changes.s
* Add a polyfill for the Node.js path module
Webpack >v5 doesn't include polyfills for core modules from Node.js by
default. Since we use `path` in the results table UI, we need to include
our own polyfill. This commit adds `path-browserify` to the
distributed extension.
As future work, we could move SARIF location rendering into the core
extension so we don't need to use `path.basename` in the UI. This would
allow us to remove the polyfill.
* Add changelog note
I don't know exactly when this can happen, but a customer has just
shown me a stack trace like this:
```
TypeError: Cannot destructure property 'resultsPath' of 'resultsPaths' as it is undefined.
at Object.interpretResults (/xxx/.vscode/extensions/github.vscode-codeql-1.4.5/out/query-results.js:120:13)
at InterfaceManager._getInterpretedResults (/xxx/.vscode/extensions/github.vscode-codeql-1.4.5/out/interface.js:377:45)
at InterfaceManager.showResultsAsDiagnostics (/xxx/.vscode/extensions/github.vscode-codeql-1.4.5/out/interface.js:447:43)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async InterfaceManager.handleMsgFromView (/xxx/.vscode/extensions/github.vscode-codeql-1.4.5/out/interface.js:151:29)
```
This commit will avoid printing this stack trace and instead print
a more descriptive message to the logs.
When codeql library developers are working on PrintAST queries, it is
not easy to use the AST Viewer. The AST Viewer caches results so that
multiple calls to view the AST of the same file are nearly
instantaneous.
However, this breaks down if you are changing the actual queries that
perform AST viewing. In this case, you do not want the cache to be
active.
This commit adds an undocumented setting that prevents caching. To
enable, set:
```
"codeQL.isCanary": true,
"codeQL.astViewer.disableCache": true
```
Note that *both* settings must be true for this to work.
This behaviour and all canary behaviour should be documented somewhere.
I will add that later.
This commit updates to webpack 5 in order to fix some dependabot errors.
Because webpack 5 introduces some breaking changes, this commit also
makes some minor changes to the build code.
One way it can fail is if the SARIF is too large. We explicitly call
out that error because the raw message received from the node runtime
is not very understandable.
Simplify description of executablePath setting
"This overrides all other CodeQL CLI settings" is a potential source of
confusion, since it suggests the RAM and threads settings may not be
passed to custom CLIs, when this is in fact the case.
"This overrides all other CodeQL CLI settings" is a potential source of
confusion, since it suggests the RAM and threads settings may not be
passed to custom CLIs, when this is in fact the case.
1. Wait a few seconds before updating the status bar after a version
change.
2. Ensure we are watching the correct configuration items for changes.
3. Ensure the cli version is refreshed correctly.
* Update typings for mocha
This is includes an update of the lock file to the v2 format. It's a big
change, but not much is happening here. I thought it best to keep it
separate.
* Fix globalSetup/teardown for mocha
Updating the typings for mocha uncovered an error in how we were
registering global setups and teardowns.
When calling `mocha.globalSetup` or `mocha.globalTeardown`, any
previously registered globals are overwritten. The workaround
is to attach globals directly to the internal options object.
This is a requirement because we are now registering globals in
multiple files.
Unfortunately, the typings for mocha do not permit this and I may need
to fix them again.
This commit does two things:
1. Add more appropriate error messages when asts can't be viewed.
2. Make better use of cached operations for asts. In the past, we were
not actually using cached operations. Each time an ast view request
occurred, we created a new TemplatePrintAstProvider instance. With this
change, we reuse the TemplatePrintAstProvider between calls and ensure
that an AST that is called once is reused on subsequent calls.
Problem was misplaced parens. We were not waiting for
the call to `pathExists` to complete before making the call
to `stat` the directory. When the directory does not
exist, then `stat` throws an error.
These functions assist with object disposal. They add custom behaviour
during disposal. The primary usage of disposalHandlers is during testing
where some objects should not be disposed in order to avoid testing
errors.
Additionally, move DisposableObject to the pure folder and create unit
tests for it.
Also, add `--disable-gpu` to command line options when running tests.
It helps to avoid error messages like this:
```- [19141:19141:0425/011526.129520:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.```
See also https://askubuntu.com/a/1288969
When someone disables and then re-enables the global telemetry setting,
the telemetry recorder needs to be recreated in order to allow it to
respond to events again.
Also, write the telemetry log item in the same telemetry processor as
is used to remove unused fields. This ensures there is no race condition
on the order of telemetry processors being run. We always log after
fields are removed.
This commit adds telemetry capturing for command execution. The data
captured explicitly captured and sent to application insights is only
the command id, execution time, and command completion status. We also
capture errors thrown by any command execution, but these are not sent
to application insights.
Telemetry capturing is opt-in. No data will be sent to application
insights unless the user explicitly allows it.
There are two new config settings added. The first controls whether or
not telemetry should be sent. This setting AND the global telemetry setting
must be enabled in order for telemetry to be sent.
The second setting controls whether or not telemetry event data should
be logged to the extension console. The hope here is that users can
inspect exactly what data is sent to the server and can have confidence
that nothing concerning is being leaked.
Note that the global setting for disabling telemetry collection is
handled inside the `vscode-extension-telemetry` package implicitly, so
this extension doesn't touch that setting explicitly.
The `codeql.canary` setting is being used to add an additional flag to
telemetry events. This flag will help us determine if a user in internal
or not.
The application insights key is injected at build time through a
repository secret.
This commit also includes a new `TELEMETRY.md` file that explains what
is being captured, and why.
This commit fixes#733. It does it by ensuring that the query server
emits an event when it restarts the query server. The database manager
listens for this even and properly re-registers its databases.
A few caveats though:
1. Convert query restarts to using a command that includes progress.
This will ensure that errors on restart are logged properly.
2. Because we want to log errors, we cannot use the vscode standard
EventEmitters. They run in the next tick and therefore any errors
will not be associated with this command execution.
3. Update the default cli version to run integration tests against to
2.4.2.
4. Add a new integration test that fails if databases are not
re-registered.
This adds two new jobs to the `Release` workflow. These
jobs are blocked behind an environment. When approved
by a committer, the extension will be deployed to
Open VSX and VS Code marketplace.
Also, update contributing docs for open-vsx publishing.
Also, hide the `CodeQL: Run Queries` command inside of zip folders
since we do not allow queries to be in archives. I wish we could be more
specific about when to show that command, eg- only *.ql files and
directories, but I couldn't find a way to restrict a command to only
appear on directories.
This removes the cached treeItem that is a property of the
completedQuery. We should not be caching them since they are cached by
the vscode api itself. Instead, we should recreate whenever requested.
Also, this change fixes#598 in a new way. Instead of adding the
context to the cached treeItem, we simply refresh only the item that has
changed. This is a fast operation.
This change avoids popping up error messages in two cases:
1. When doing test discovery, do not run discovery on non-existant
directories. Also, if there is an error, print to the log, and do not
pop up an error window. The reason is that test discovery is a
background operation and these should not normally cause pop-ups.
2. When looking for orphaned databases, don't pop up an error if the
storagePath can't be found. This is normal when working in a new,
single root workspace.
* Now query.test.ts runs on multiple cli versions
* Removed most `dispose` calls in cli tests because each test shares the
same instance of the extension and all of its properties. So, we
shouldn't be disposing until the last test completes. It's likely that
we will need to be more careful about cleaning up state between test
runs, but we haven't hit that yet and this can happen in a later
commit.
* Requires that QL_PATH environment variable is set and points to a
checkout of github/codeql
* Adds the `quiet` flag to the cli. When set, this flag will prevent
some modal dialogs from disrupting the flow. Currently, we only ensure
that the upgrades dialog is avoided.
* Update the main.yml workflow to checkout the codeql repo
This fixes two classes of DBs that can't be installed directly from
downloading:
1. DBs whose central directories do not align with their file headers.
We need to download and save the entire archive before we can read
the central directory and use that to guide the unzipping.
2. Large DBs require too much memory so can't be downloaded and unzipped
in a single stream.
We also add proper progress notifications to the download progress
monitor so users are aware of how many more MBs are left to download.
It's not yet possible to do the same for unzipping using the current
unzipper library, since unzipping using the central directory does not
expose a stream.
Co-authored-by: Alexander Eyers-Taylor <alexet@github.com>
1. Clicking on query history menu items when nothing is selected. Error
message is clearer. It would be better to disable when nothing is
selected, but waiting on
https://github.com/microsoft/vscode/issues/99767 to be released.
2. Trying to run query with a missing or invalid qlpack has better
message.
3. Better hover text for "Open query".
Co-authored-by: Aditya Sharad <6874315+adityasharad@users.noreply.github.com>
In order to do this, needed to add a few extra pieces:
* extracted the simple database download so that it only happens
once and is shared across all tests.
* needed to update mocha to latest version since that has the new API
* But typings isn't updated yet, so submitted a PR into DefinitelyTyped
for that.
* Added a concept of helper files for test runs. These helper files
will contain all the shared global setup.
Unfortunately, at this point, we can't run using a language pack since
we would also need to download the the ql repository from somewhere.
This commit adds integration tests that run commands using the CLI. This
change introduces a number of enhancements in order to get there.
1. Augments the index-template.ts file so that it downloads an
appropriate cli version if requested.
2. Adds the ensureCli.ts that performs the download if a a suitable
version is not already installed. See the comments in the file for how
this is done.
3. Changes how run-integration-tests is done so that the directories
run are specified through a cli argument.
4. Updates the main.yml workflow so that it also runs the
cli-integration tests.
5. Takes advantage of the return value of the call to `activate` on the
extension. This allows the integration tests to have access to internal
variables of the extension like the context, cli, and query server.
6. And of course, adds a handful of simple tests that ensure we have a
cli installed of the correct version.
This commit moves to using codeql resolve database instead of inspecting
the `codeql-database.yml` file.
When the extension starts and if the cli supports it, the extension will
attempt to get the name for any databases that don't yet have a name.
Once a name is searched for once by the cli, it will be cached so we
don't need to rediscover the name again.
This change will only work on databases created by cli >= 2.4.1. In that
version, a new `primaryLanguage` field in the `codeql-database.yml`
file. We use this property as the language.
This change also includes a refactoring of the logic around extracting
database information heuristically based on file location. As much
as possible, it is extracted to the `helpers` module. Also, the
initial quick query text is generated based on the language (if known)
otherwise it falls back to the old style of generation.
* Fix dubious index check
* Add unit tests for add/remove database
In order to do this, needed to move `databases.test.ts` to the
`minimal-workspace` test folder because these tests require that there
be some kind of workspace open in order to check on workspace folders.
Unfortunately, during tests vscode does not allow you to convert from a
single root workspace to multi-root and so several of the workspace
functions needed to be stubbed out.
* Update changelog
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
And separate flag for IDE server. Setting these flags to `true` will
start the respective Java processes in debug mode so that they can
be attached to a debugger.
Cleans orphan databases on startup. This commit also bumps the fs-extra
dependency to get readdir with dirent objects.
Adds the `asyncFilter` to filter arrays asynchronously.
The diff and the errors were always available, but they were not being
sent to the output.
Additionally, make sure to send output to both the test explorer log and
the codeql test log.
With this change we display the tree based on the file system not based
on ql-packs. We also merge test folders whose only child is another
test folder.
Resolves#595
This fixes a bug where if there are special characters in a database
path, it is not possible to navigate to that file from the results view.
Note that the results from our BQRS returned properly encoded URIs, but
our paths coming from sarif were unencoded. Our path parsing handled
the latter correctly (even though these are not correct URIs) and the
former incorrectly.
The fix here is to first ensure all uris are properly encoded. We do
this by running `encodeURI` in sarif-utils (can't run encodeURIComponent
or else the path separators `/` will also be encoded).
Then, we ensure that when we resolve locations, we decode all file
paths.
This works in all cases I have tried. I still have an issue with running
View AST on some of these databases, but that I believe is a separate
issue.
This query ensures that all of our files marked as "pure" remain that
way. In this case "pure" means that it does not depend on vscode and
can therefore be run in tests outside of a runtime environment.
This commit also explicitly moves all of our "pure" files to the
`src/pure` directory.
This commit fixes a bug uncovered by
c66fe07b06.
The findSourceArchive function in databases.ts creates a
codeql-zip-archive uri with an empty authority component. This will
fail to decode. Until recently, this situation never happened. But in
the commit linked above, we start decoding some of these incorrectly
encoded uris.
This commit fixes that issue.
Also, refactor resolveSourceFile to make it easier to read.
And add unit tests for resolveSourceFile.
This commit fixes a bug in resolveSourceFile where the
`pathWithinSourceArchive` was being removed and appended to the
`sourceArchiveZipPath`. In normal situations, we don't hit this bug
because most database source archive uris have an empty path for the
`pathWithinSourceArchive`.
Split commandRunner into two functions: commandRunner and
commandRunnerWithProgress.
Also, take advantage of default arguments for ProgressOptions.
And updates changelog.
When a user runs multiple queries on a non-upgraded database, ensure
that only one dialog appears for upgrade.
This commit also migrates the upgrades.ts file to using the passed-in
cancellation token and progress monitor. This ensures that cancelling
a database upgrade command will also cancel out of any wrapper
operations.
Fixes#534
The commandRunner wraps all vscode command registrations. It provides
uniform error handling and an optional progress monitor.
In general, progress monitors should only be created by the
commandRunner and passed through to the locations that use it.
This commit adds DatabaseChangedEvent and ensures that all events
fired by the DatabaseManager includes one of these kinds.
Currently, the only kind that we care about is `Remove`. We ensure that
the problems view is only cleared on Remove events.
This commit fixes the problem whereby a database is removed and the
problems associated with queries run from that database stick around
in the problems view.
Also, once problems are cleared, we need to make sure that we uncheck
the checkbox in the results view.
This commit has several limitations:
1. There is duplicated code for message handling in both results.tsx and
result-tables.tsx.
2. Problems are cleared whenever there is *any* change to any database.
Ideally we should only clear problems when a database is removed and
only problems associated with that database. I'll fix part of this in
a future commit.
Resolves#525
When a user clicks in an editor that whose source tree is currently being displayed in
the ast viewer, the viewer selection will stay in sync with the editor selection.
Problem was that we were not globally replaceing `\\` with `\`.
Also, this PR adds some new tests to sarif-utils.ts. In doing so, we
have fixed a small bug in getPathRelativeToSourceLocationPrefix.
Previously, we were uri decoding the sarifRelativeUri. However, this is
no longer correct because the result is another URI and it should
remain encoded if it originally was.
Resolves#585
When retrieving paginated results, need to make sure we are getting
page offsets from the correct results file.
Previously, we were incorrectly extracting page offsets from the default
(unsorted) file. With this change, we ensure that we get offsets from
the proper results file when there is a request for a page of results.
* It is now more general and the logic is simplified
* Also, add more comments
* Rename `adaptBqrs` to `transformBqrsResultSet`
* Remove a react error for missing a key attribute in a list
This refactoring combines the types in `bqrs-types.ts` and
`bqrs-cli-types.ts`. Historically, the former was used for BQRS files
parsed by the extension and the latter for BQRS files parsed by the cli.
They describe the same file types, but using different property and type
names.
We have moved to parsing all BQRS files by the cli. This refactoring
removes the `bqrs-types.ts` file and replaces all BQRS references to
use types in `bqrs-cli-types.ts`.
Additionally, the `adapt.ts` file has been deleted since its purpose
was to convert between extension and cli BQRS types. Some one type and
one function from `adapt.ts` has been moved from `adapt.ts` to
`bqrs-types.ts`. It's possible that we want to do a further refactoring
to simply remove them both.
A common situation when a file is not relevant for a particular result
is to return an empty file path location.
Currently, we are displaying this situation as a hyperlink in the
results, but when clicking on the link, there is an error.
To mirror the behaviour of Eclipse, we should avoid showing a link here.
This commit changes that behaviour.
Fixes#543
```ql
newtype TA = TB()
private predicate foo() { any() }
```
Our TextMate grammar didn't realize that the newtype declaration ended after the closing paren of the branch's parameter list, so the `private` modifier was highlighted incorrectly.
It's surprisingly tricky to get TextMate to handle this correctly, so I wound up just treating the IPA declaration head (`newtype TA`), the branch head (`= TB`), the branch parameter list, and the branch body as directly children of the module body. This is kind of hacky, but it does fix the bug without introducing any new cases where we have incorrect highlighting of valid code.
This leads to less sharing of codepaths which is a little bad (slightly more
repetition and rendundancy) but a lot good (can independently fix the way
raw results are redisplayed so as to be actually correct).
qlpack tests that are not contained within the current workspace folder
will be filtered from the test runner view.
This also fixes a test that should have been failing but wasn't.
We need to provide the `--extensionDevelopmentPath` flag in these
launch configurations.
It appears to be unnecessary to include
`${workspaceRoot}/extensions/ql-vscode/out/vscode-tests/**/*.js`
in addition to the strictly more general pattern
${workspaceRoot}/extensions/ql-vscode/out/**/*.js
An unfortunate UI fact appears to be that the log of the gulp build is
focused whenever these tasks are run, even though the log you actually
care about seeing is in the `Debug Console` section. Not sure how to
fix that.
When there are no results, always ensure that max pages is 1.
This commit also changes the way pagination buttons are displayed,
removing their border.
* Fix command-linting tests.
* Fix failing windows test and Use Uri.parse(_, true)
* Use Uri.parse(_, true). That is the preferred API.
* Reformat comments.
This commit adds the AST Viewer for viewing the QL AST of a file in a
database.
The different components are as follows:
1. There is a new view `codeQLAstViewer`, which displays the AST
2. This view is backed by the `AstViewerDataProvider` and `AstViewer` classes in astView.ts
3. To generate an AST, we use contextual queries, similar to how Find references/declarations are implemented. In particular, in `definitions.ts` there is `TemplatePrintAstProvider` which provides an AST for a given source buffer.
- Similar to the other queries, we first determine which database the buffer belongs to.
- Based on that, we generate a synthetic qlpack and run the templatized `printAst.ql` query
- We plug in the archive-relative path name of the source file.
- After the query is run, we wrap the results in an `AstBuilder` instance.
- When requested, the `AstBuilder` will generate the full AST of the file from the BQRS results.
- The AST roots (all top-level elements, functions, variable declarations, etc, are roots) are passed to the `AstViewer` instance, which handles the display lifecycle and other VS Code-specific functions.
There are a few unrelated pieces here, which can be pulled out to another PR if required:
- The `codeQLQueryHistory` view now has a _welcome_ message to make it more obvious to users how to start.
- `definitions.ts` is moved to the `contextual` subfolder.
- `fileRangeFromURI` is extracted from `definitions.ts` to its own file so it can be reused.
Also, note that this relies on https://github.com/github/codeql/pull/3931 for the C/C++ query to be available in the QL sources. Other languages will need similar queries.
Apparently the linter wants a tsconfig file to be able to lint the
compare view typescript. I made the configFile specification in the
webpack.config.ts more specific so that we use the same config
every time during webview build.
Without this `configFile` option, ts-loader apparently does not
guarantee a deterministic choice of which of the three `tsconfig.json`
files below `extensions/ql-vscode` actually gets used during webpack.
This leads to very strange behavior as even removing dead code can
change which `tsconfig.json` 'wins the race'. I observed that removing
a dependence on `semmle-bqrs` from `src/view` *tended* to make
`ts-loader` choose `src/compare/view/tsconfig.json` instead.
* Fix command-linting tests.
* Fix failing windows test and Use Uri.parse(_, true)
* Use Uri.parse(_, true). That is the preferred API.
* Reformat comments.
This commit adds the AST Viewer for viewing the QL AST of a file in a
database.
The different components are as follows:
1. There is a new view `codeQLAstViewer`, which displays the AST
2. This view is backed by the `AstViewerDataProvider` and `AstViewer` classes in astView.ts
3. To generate an AST, we use contextual queries, similar to how Find references/declarations are implemented. In particular, in `definitions.ts` there is `TemplatePrintAstProvider` which provides an AST for a given source buffer.
- Similar to the other queries, we first determine which database the buffer belongs to.
- Based on that, we generate a synthetic qlpack and run the templatized `printAst.ql` query
- We plug in the archive-relative path name of the source file.
- After the query is run, we wrap the results in an `AstBuilder` instance.
- When requested, the `AstBuilder` will generate the full AST of the file from the BQRS results.
- The AST roots (all top-level elements, functions, variable declarations, etc, are roots) are passed to the `AstViewer` instance, which handles the display lifecycle and other VS Code-specific functions.
There are a few unrelated pieces here, which can be pulled out to another PR if required:
- The `codeQLQueryHistory` view now has a _welcome_ message to make it more obvious to users how to start.
- `definitions.ts` is moved to the `contextual` subfolder.
- `fileRangeFromURI` is extracted from `definitions.ts` to its own file so it can be reused.
Also, note that this relies on https://github.com/github/codeql/pull/3931 for the C/C++ query to be available in the QL sources. Other languages will need similar queries.
A user typically expects that the first selection would be
the query that they are comparing _from_ and the second query
is being compared _to_.
This commit ensures that something like this expectation will
always hold.
So, when there are two queries selected, the first one selected
will always be _from_ and appear on the left side of the compare
view. The one selected later will be _to_ and appear on the right.
There is a corner case when there are 3 or more selected queries
and a user *unselects* a query. We do not track the selection
order of the remaining two queries.
New command called `codeQL.runQueries`.
When invoked, gather all selected files and folders, and recursively
search for ql files to run. Warn the user if a directory is selected.
See comment inline for reason.
This is not quite ideal due to
https://github.com/microsoft/vscode/issues/99767
Allow multiselection in the query-history view. For commands
that shouldn't accept multiple options, show a user message
to that effect.
For remove query, allow multiple removals at once.
For compare query, allow selecting of exactly two queries.
Otherwise, throw an error. Also, verify that the selected queries
are compatible to compare.
* The error message will be displayed instead of the empty results
tables.
* Also, uncomment onEnterRules. That should never have been committed.
* Also, extract CompareTable to its own component.
I have already pushed `main` upstream pointing at the same commit as
master, so this PR should be safe to merge. To the best of my
knowledge all that's necessary after that is to change the
default branch
in https://github.com/github/vscode-codeql/settings/branches.
Use the same mechanism that we are using for log files to open
large sarif files. This is because the extension is not
capable of opening large (>50MB) files due to vscode restrictions.
When the `env.language` value is not passed as the locale, OS-default
locale is used. This change ensures that we use the workspace locale
where we want and explicitly calls out where we should continue to use
the OS-default.
Suppose a user has the includePrereleases config option set, installs an
extension-managed prerelease, then decides they no longer want
prereleases and disables includePrereleases.
In this case, we should prompt the user to downgrade the CLI to a
non-prerelease version.
However, if the user is managing their own CLI, we will allow them to
use prereleases without incompatibility prompts.
There are some flaky CI test failures that manifest only as a message
like
[main 2020-06-01T16:09:47.671Z] [VS Code]: render process crashed!
(and only afaict on windows) which I am not sure how to detect at the
moment. If that message is occurring in the exception caught at this
stage, we can check for it.
about: Create an issue with a checklist for the release steps (write access required
for the steps)
title: Release Checklist for version xx.xx.xx
labels: ''
assignees: ''
---
- [ ] Update this issue title to refer to the version of the release
- [ ] Trigger a release build on Actions by adding a new tag on master of the format `vxx.xx.xx`
- [ ] Monitor the status of the release build in the `Release` workflow in the Actions tab.
- [ ] Download the VSIX from the draft GitHub release that is created when the release build finishes.
- [ ] Log into the [Visual Studio Marketplace](https://marketplace.visualstudio.com/manage/publishers/github).
- [ ] Click the `...` menu in the CodeQL row and click **Update**.
- [ ] Drag the `.vsix` file you downloaded from the GitHub release into the Marketplace and click **Upload**.
- [ ] Publish the draft GitHub release and confirm the new release is marked as the latest release at https://github.com/github/vscode-codeql/releases.
Replace this with a description of the changes your pull request makes.
## Checklist
- [ ] [CHANGELOG.md](https://github.com/github/vscode-codeql/blob/master/extensions/ql-vscode/CHANGELOG.md) has been updated to incorporate all user visible changes made by this pull request.
- [ ] [CHANGELOG.md](https://github.com/github/vscode-codeql/blob/main/extensions/ql-vscode/CHANGELOG.md) has been updated to incorporate all user visible changes made by this pull request.
- [ ] Issues have been created for any UI or other user-facing changes made by this pull request.
- [ ]`@github/product-docs-dsp` has been cc'd in all issues for UI or other user-facing changes made by this pull request.
- [ ]_[Maintainers only]_ If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the [github/codeql](https://github.com/github/codeql/tree/main/docs/codeql/codeql-for-visual-studio-code) repo and add the `ready-for-doc-review` label there.
"typescript.tsdk":"./common/temp/node_modules/typescript/lib",// we want to use the TS server from our node_modules folder to control its version
"typescript.tsdk":"./extensions/ql-vscode/node_modules/typescript/lib",// we want to use the TS server from our node_modules folder to control its version
"typescript.enablePromptUseWorkspaceTsdk":true,
"eslint.validate":[
"javascript",
"javascriptreact",
"typescript",
"typescriptreact"
],
"eslint.options":{
// This is necessary so that eslint can properly resolve its plugins
@@ -25,94 +25,41 @@ Here are a few things you can do that will increase the likelihood of your pull
* Follow the [style guide][style].
* Write tests. Tests that don't require the VS Code API are located [here](extensions/ql-vscode/test). Integration tests that do require the VS Code API are located [here](extensions/ql-vscode/src/vscode-tests).
* Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
* Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
* Write a [good commit message](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
## Setting up a local build
Make sure you have a fairly recent version of vscode (>1.32) and are using nodejs
version >=v10.13.0. (Tested on v10.15.1 and v10.16.0).
Make sure you have installed recent versions of vscode, node, and npm. Check the `engines` block in [`package.json`](https://github.com/github/vscode-codeql/blob/main/extensions/ql-vscode/package.json) file for compatible versions. Earlier versions may work, but we no longer test against them.
This repo uses [Rush](https://rushjs.io) to handle package management, building, and other
operations across multiple projects. See the Rush "[Getting started as a developer](https://rushjs.io/pages/developer/new_developer/)" docs
for more details.
To automatically switch to the correct version of node, we recommend using [nvm](https://github.com/nvm-sh/nvm), which will pick-up the node version from `.nvmrc`.
If you plan on building from the command line, it's easiest if Rush is installed globally:
### Installing all packages
From the command line, go to the directory `extensions/ql-vscode` and run
```shell
npm install -g @microsoft/rush
npm install
```
To get started, run:
### Building the extension
From the command line, go to the directory `extensions/ql-vscode` and run
```shell
rush update && rush build
npm run build
npm run watch
```
Note that when you run the `rush` command from the globally installed version, it will examine the
`rushVersion` property in the repo's `rush.json`, and if it differs from the globally installed
version, it will download, cache, and run the version of Rush specified in the `rushVersion`
property.
Alternatively, you can build the extension within VS Code via `Terminal > Run Build Task...` (or `Ctrl+Shift+B` with the default key bindings). And you can run the watch command via `Terminal > Run Task` and then select `npm watch` from the menu.
A few more things to know about using rush:
Before running any of the launch commands, be sure to have run the `build` command to ensure that the JavaScript is compiled and the resources are copied to the proper location.
* Avoid running `npm` for any commands that install/link dependencies
* Instead use the *rush* equivalent: `rush add <package>`, `rush update`, etc.
* If you plan on only building via VS Code tasks, you don't need Rush installed at all, since those
tasks run `common/scripts/install-run-rush.js` to bootstrap a locally installed and cached copy of
Rush.
We recommend that you keep `npm run watch` running in the backgound and you only need to re-run `npm run build` in the following situations:
### Building
1. on first checkout
2. whenever any of the non-TypeScript resources have changed
#### Installing all packages (instead of `npm install`)
After updating any `package.json` file, or after checking or pulling a new branch, you need to
make sure all the right npm packages are installed, which you would normally do via `npm install` in
a single-project repo. With Rush, you need to do an "update" instead:
##### From VS Code
`Terminal > Run Task... > Update`
##### From the command line
```shell
rush update
```
#### Building all projects (instead of `gulp`)
Rush builds all projects in the repo, in dependency order, building multiple projects in parallel
where possible. By default, the build also packages the extension itself into a .vsix file in the
`dist` directory. To build:
##### From VS Code
`Terminal > Run Build Task...` (or just `Ctrl+Shift+B` with the default key bindings)
##### From the command line
```shell
rush build --verbose
```
#### Forcing a clean build
Rush does a reasonable job of detecting on its own which projects need to be rebuilt, but if you need to
force a full rebuild of all projects:
##### From VS Code
`Terminal > Run Task... > Rebuild`
##### From the command line
```shell
rush rebuild --verbose
```
Note that `rush rebuild` performs a complete rebuild, whereas `rush build` performs an incremental build and in many cases will not need to do anything at all.
### Installing
### Installing the extension
You can install the `.vsix` file from within VS Code itself, from the Extensions container in the sidebar:
@@ -130,38 +77,187 @@ $ vscode/scripts/code-cli.sh --install-extension dist/vscode-codeql-*.vsix # if
You can use VS Code to debug the extension without explicitly installing it. Just open this directory as a workspace in VS Code, and hit `F5` to start a debugging session.
### Running the unit/integration tests
### Storybook
Ensure the `CODEQL_PATH` environment variable is set to point to the `codeql`cli executable.
Outside of vscode, run:
You can use [Storybook](https://storybook.js.org/) to preview React components outside VSCode. Inside the `extensions/ql-vscode`directory, run:
```shell
npm run test&& npm run integration
npm run storybook
```
Alternatively, you can run the tests inside of vscode. There are several vscode launch configurations defined that run the unit and integration tests. They can all be found in the debug view.
Your browser should automatically open to the Storybook UI. Stories live in the `src/stories` directory.
Alternatively, you can start Storybook inside of VSCode. There is a VSCode launch configuration for starting Storybook. It can be found in the debug view.
More information about Storybook can be found inside the **Overview** page once you have launched Storybook.
### Testing
We have several types of tests:
* Unit tests: these live in the `tests/pure-tests/` directory
* View tests: these live in `src/view/variant-analysis/__tests__/`
* VSCode integration tests: these live in `src/vscode-tests/no-workspace` and `src/vscode-tests/minimal-workspace`
* CLI integration tests: these live in `src/vscode-tests/cli-integration`
The CLI integration tests require an instance of the CodeQL CLI to run so they will require some extra setup steps. When adding new tests to our test suite, please be mindful of whether they need to be in the cli-integration folder. If the tests don't depend on the CLI, they are better suited to being a VSCode integration test.
#### Running the tests
##### 1. From the terminal
First move into the `extensions/ql-vscode` directory. Then, depending on which tests you want to run, use the appropriate command to run the tests:
* Unit tests: `npm run test:unit`
* View Tests: `npm test:view`
* VSCode integration tests: `npm run integration`
###### CLI integration tests
The CLI integration tests require the CodeQL standard libraries in order to run so you will need to clone a local copy of the `github/codeql` repository.
1. Set the `TEST_CODEQL_PATH` environment variable: running from a terminal, you _must_ set the `TEST_CODEQL_PATH` variable to point to a checkout of the `github/codeql` repository. The appropriate CLI version will be downloaded as part of the test.
2. Run your test command:
```shell
cd extensions/ql-vscode && npm run cli-integration
```
##### 2. From VSCode
Alternatively, you can run the tests inside of VSCode. There are several VSCode launch configurations defined that run the unit and integration tests.
You will need to run tests using a task from inside of VS Code, under the "Run and Debug" view:
* Unit tests: run the _Launch Unit Tests - React_ task
* View Tests: run the _Launch Unit Tests_ task
* VSCode integration tests: run the _Launch Unit Tests - No Workspace_ and _Launch Unit Tests - Minimal Workspace_ tasks
###### CLI integration tests
The CLI integration tests require the CodeQL standard libraries in order to run so you will need to clone a local copy of the `github/codeql` repository.
1. Set the `TEST_CODEQL_PATH` environment variable: running from a terminal, you _must_ set the `TEST_CODEQL_PATH` variable to point to a checkout of the `github/codeql` repository. The appropriate CLI version will be downloaded as part of the test.
2. Set the codeql path in VSCode's launch configuration: open `launch.json` and under the _Launch Integration Tests - With CLI_ section, uncomment the `"${workspaceRoot}/../codeql"` line. If you've cloned the `github/codeql` repo to a different path, replace the value with the correct path.
3. Run the VSCode task from the "Run and Debug" view called _Launch Integration Tests - With CLI_.
#### Using a mock GitHub API server
Multi-Repo Variant Analyses (MRVA) rely on the GitHub API. In order to make development and testing easy, we have functionality that allows us to intercept requests to the GitHub API and provide mock responses.
##### Using a pre-recorded test scenario
To run a mock MRVA scenario, follow these steps:
1. Enable the mock GitHub API server by adding the following in your VS Code user settings (which can be found by running the `Preferences: Open User Settings (JSON)` VS Code command):
```json
"codeQL.mockGitHubApiServer":{
"enabled":true
}
```
1. Run the `CodeQL: Mock GitHub API Server: Load Scenario` command from the command pallet, and choose one of the scenarios to load.
1. Execute a normal MRVA. At this point you should see the scenario being played out, rather than an actual MRVA running.
1. Once you're done, you can stop using the mock scenario with `CodeQL: Mock GitHub API Server: Unload Scenario`
If you want to replay the same scenario you should unload and reload it so requests are replayed from the start.
##### Recording a new test scenario
To record a new mock MRVA scenario, follow these steps:
1. Enable the mock GitHub API server by adding the following in your VS Code user settings (which can be found by running the `Preferences: Open User Settings (JSON)` VS Code command):
```json
"codeQL.mockGitHubApiServer":{
"enabled":true
}
```
1. Run the `CodeQL: Mock GitHub API Server: Start Scenario Recording` VS Code command from the command pallet.
1. Execute a normal MRVA.
1. Once what you wanted to record is done (e.g. the MRVA has finished), then run the `CodeQL: Mock GitHub API Server: Save Scenario` command from the command pallet.
1. The scenario should then be available for replaying.
If you want to cancel recording, run the `CodeQL: Mock GitHub API Server: Cancel Scenario Recording` command.
Once the scenario has been recorded, it's often useful to remove some of the requests to speed up the replay, particularly ones that fetch the variant analysis status. Once some of the request files have manually been removed, the [fix-scenario-file-numbering script](./extensions/ql-vscode/scripts/fix-scenario-file-numbering.ts) can be used to update the number of the files. See the script file for details on how to use.
#### Scenario data location
Pre-recorded scenarios are stored in `./src/mocks/scenarios`. However, it's possible to configure the location, by setting the `codeQL.mockGitHubApiServer.scenariosPath` configuration property in the VS Code user settings.
## Releasing (write access required)
1. Double-check the `CHANGELOG.md` contains all desired change comments
and has the version to be released with date at the top.
1. Double-check that the extension `package.json` has the version you intend to release.
If you are doing a patch release (as opposed to minor or major version) this should already
be correct.
1. Trigger a release build on Actions by adding a new tag on master of the format `vxx.xx.xx`
1. Double-check the `CHANGELOG.md` contains all desired change comments and has the version to be released with date at the top.
* Go through all recent PRs and make sure they are properly accounted for.
* Make sure all changelog entries have links back to their PR(s) if appropriate.
1. Double-check that the node version we're using matches the one used for VS Code. If it doesn't, you will then need to update the node version in the following files:
*`.nvmrc` - this will enable `nvm` to automatically switch to the correct node version when you're in the project folder
*`.github/workflows/main.yml` - all the "node-version: <version>" settings
*`.github/workflows/release.yml` - the "node-version: <version>" setting
1. Double-check that the extension `package.json` and `package-lock.json` have the version you intend to release. If you are doing a patch release (as opposed to minor or major version) this should already be correct.
1. Create a PR for this release:
* This PR will contain any missing bits from steps 1 and 2. Most of the time, this will just be updating `CHANGELOG.md` with today's date.
* Create a new branch for the release named after the new version. For example: `v1.3.6`
* Create a new commit with a message the same as the branch name.
* Create a PR for this branch.
* Wait for the PR to be merged into `main`
1. Switch to `main` and add a new tag on the `main` branch with your new version (named after the release), e.g.
```bash
git checkout main
git tag v1.3.6
```
If you've accidentally created a badly named tag, you can delete it via
```bash
git tag -d badly-named-tag
```
1. Push the new tag up:
a. If you're using a fork of the repo:
```bash
git push upstream refs/tags/v1.3.6
```
b. If you're working straight in this repo:
```bash
git push origin refs/tags/v1.3.6
```
This will trigger [a release build](https://github.com/github/vscode-codeql/releases) on Actions.
* **IMPORTANT** Make sure you are on the `main` branch and your local checkout is fully updated when you add the tag.
* If you accidentally add the tag to the wrong ref, you can just force push it to the right one later.
1. Monitor the status of the release build in the `Release` workflow in the Actions tab.
* DO NOT approve the "publish" stages of the workflow yet.
1. Download the VSIX from the draft GitHub release at the top of [the releases page](https://github.com/github/vscode-codeql/releases) that is created when the release build finishes.
1. Optionally unzip the `.vsix` and inspect its `package.json` to make sure the version is what you expect,
1. Unzip the `.vsix` and inspect its `package.json` to make sure the version is what you expect,
or look at the source if there's any doubt the right code is being shipped.
1. Log into the [Visual Studio Marketplace](https://marketplace.visualstudio.com/manage/publishers/github).
1. Click the `...` menu in the CodeQL row and click **Update**.
1. Drag the `.vsix` file you downloaded from the GitHub release into the Marketplace and click **Upload**.
1. Go to the draft GitHub release, click 'Edit', add some summary description, and publish it.
1. Install the `.vsix` file into your vscode IDE and ensure the extension can load properly. Run a single command (like run query, or add database).
1. Go to the actions tab of the vscode-codeql repository and select the [Release workflow](https://github.com/github/vscode-codeql/actions?query=workflow%3ARelease).
- If there is an authentication failure when publishing, be sure to check that the authentication keys haven't expired. See below.
1. Approve the deployments of the correct Release workflow. This will automatically publish to Open VSX and VS Code Marketplace.
1. Go to the draft GitHub release in [the releases tab of the repository](https://github.com/github/vscode-codeql/releases), click 'Edit', add some summary description, and publish it.
1. Confirm the new release is marked as the latest release at <https://github.com/github/vscode-codeql/releases>.
1. If documentation changes need to be published, notify documentation team that release has been made.
1. Review and merge the version bump PR that is automatically created by Actions.
## Secrets and authentication for publishing
Repository administrators, will need to manage the authentication keys for publishing to the VS Code marketplace and Open VSX. Each requires an authentication token. The VS Code marketplace token expires yearly.
To regenerate the Open VSX token:
1. Log in to the [user settings page on Open VSX](https://open-vsx.org/user-settings/namespaces).
1. Make sure you are a member of the GitHub namespace.
1. Go to the [Access Tokens](https://open-vsx.org/user-settings/tokens) page and generate a new token.
1. Update the secret in the `publish-open-vsx` environment in the project settings.
To regenerate the VSCode Marketplace token, please see our internal documentation. Note that Azure DevOps PATs expire every 90 days and must be regenerated.
## Resources
* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
@@ -4,7 +4,7 @@ This project is an extension for Visual Studio Code that adds rich language supp
The extension is released. You can download it from the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=github.vscode-codeql).
To see what has changed in the last few versions of the extension, see the [Changelog](https://github.com/github/vscode-codeql/blob/master/extensions/ql-vscode/CHANGELOG.md).
To see what has changed in the last few versions of the extension, see the [Changelog](https://github.com/github/vscode-codeql/blob/main/extensions/ql-vscode/CHANGELOG.md).
[](https://github.com/github/vscode-codeql/actions?query=workflow%3A%22Build+Extension%22+branch%3Amaster)
- Fix a bug where databases may be lost if VS Code is restarted while the extension is being started up. [#1638](https://github.com/github/vscode-codeql/pull/1638)
- Add commands for navigating up, down, left, or right in the result viewer. Previously there were only commands for moving up and down the currently-selected path. We suggest binding keyboard shortcuts to these commands, for navigating the result viewer using the keyboard. [#1568](https://github.com/github/vscode-codeql/pull/1568)
## 1.7.2 - 14 October 2022
- Fix a bug where results created in older versions were thought to be unsuccessful. [#1605](https://github.com/github/vscode-codeql/pull/1605)
## 1.7.1 - 12 October 2022
- Fix a bug where it was not possible to add a database folder if the folder name starts with `db-`. [#1565](https://github.com/github/vscode-codeql/pull/1565)
- Ensure the results view opens in an editor column beside the currently active editor. [#1557](https://github.com/github/vscode-codeql/pull/1557)
## 1.7.0 - 20 September 2022
- Remove ability to download databases from LGTM. [#1467](https://github.com/github/vscode-codeql/pull/1467)
- Remove the ability to manually upgrade databases from the context menu on databases. Databases are non-destructively upgraded automatically so for most users this was not needed. For advanced users this is still available in the Command Palette. [#1501](https://github.com/github/vscode-codeql/pull/1501)
- Always restart the query server after a manual database upgrade. This avoids a bug in the query server where an invalid dbscheme was being retained in memory after an upgrade. [#1519](https://github.com/github/vscode-codeql/pull/1519)
## 1.6.12 - 1 September 2022
- Add ability for users to download databases directly from GitHub. [#1485](https://github.com/github/vscode-codeql/pull/1485)
- Fix a race condition that could cause a failure to open the evaluator log when running a query. [#1490](https://github.com/github/vscode-codeql/pull/1490)
- Fix an error when running a query with an older version of the CodeQL CLI. [#1490](https://github.com/github/vscode-codeql/pull/1490)
## 1.6.11 - 25 August 2022
No user facing changes.
## 1.6.10 - 9 August 2022
No user facing changes.
## 1.6.9 - 20 July 2022
No user facing changes.
## 1.6.8 - 29 June 2022
- Fix a bug where quick queries cannot be compiled if the core libraries are not in the workspace. [#1411](https://github.com/github/vscode-codeql/pull/1411)
- Fix a bug where quick evaluation of library files would display an error message when using CodeQL CLI v2.10.0. [#1412](https://github.com/github/vscode-codeql/pull/1412)
## 1.6.7 - 15 June 2022
- Prints end-of-query evaluator log summaries to the Query Log. [#1349](https://github.com/github/vscode-codeql/pull/1349)
- Be consistent about casing in Query History menu. [#1369](https://github.com/github/vscode-codeql/pull/1369)
- Fix quoting string columns in exported CSV results. [#1379](https://github.com/github/vscode-codeql/pull/1379)
## 1.6.6 - 17 May 2022
No user facing changes.
## 1.6.5 - 25 April 2022
- Re-enable publishing to open-vsx. [#1285](https://github.com/github/vscode-codeql/pull/1285)
## 1.6.4 - 6 April 2022
No user facing changes.
## 1.6.3 - 4 April 2022
- Fix a bug where the AST viewer was not synchronizing its selected node when the editor selection changes. [#1230](https://github.com/github/vscode-codeql/pull/1230)
- Avoid synchronizing the `codeQL.cli.executablePath` setting. [#1252](https://github.com/github/vscode-codeql/pull/1252)
- Open the directory in the finder/explorer (instead of just highlighting it) when running the "Open query directory" command from the query history view. [#1235](https://github.com/github/vscode-codeql/pull/1235)
- Ensure query label in the query history view changes are persisted across restarts. [#1235](https://github.com/github/vscode-codeql/pull/1235)
- Prints end-of-query evaluator log summaries to the Query Server Console. [#1264](https://github.com/github/vscode-codeql/pull/1264)
## 1.6.1 - 17 March 2022
No user facing changes.
## 1.6.0 - 7 March 2022
- Fix a bug where database upgrades could not be resolved if some of the target pack's dependencies are outside of the workspace. [#1138](https://github.com/github/vscode-codeql/pull/1138)
- Open the query server logs for query errors (instead of the extension log). This will make it easier to track down query errors. [#1158](https://github.com/github/vscode-codeql/pull/1158)
- Fix a bug where queries took a long time to run if there are no folders in the workspace. [#1157](https://github.com/github/vscode-codeql/pull/1157)
- [BREAKING CHANGE] The `codeQL.runningQueries.customLogDirectory` setting is deprecated and no longer has any function. Instead, all query log files will be stored in the query history directory, next to the query results. [#1178](https://github.com/github/vscode-codeql/pull/1178)
- Add a _Open query directory_ command for query items. This command opens the directory containing all artifacts for a query. [#1179](https://github.com/github/vscode-codeql/pull/1179)
- Add options to display evaluator logs for a given query run. Some information that was previously found in the query server output may now be found here. [#1186](https://github.com/github/vscode-codeql/pull/1186)
## 1.5.11 - 10 February 2022
- Fix a bug where invoking _View AST_ from the file explorer would not view the selected file. Instead it would view the active editor. Also, prevent the _View AST_ from appearing if the current selection includes a directory or multiple files. [#1113](https://github.com/github/vscode-codeql/pull/1113)
- Add query history items as soon as a query is run, including new icons for each history item. [#1094](https://github.com/github/vscode-codeql/pull/1094)
- Save query history items across restarts. Items will be saved for 30 days and can be overwritten by setting the `codeQL.queryHistory.ttl` configuration setting. [#1130](https://github.com/github/vscode-codeql/pull/1130)
- Allow in-progress query items to be cancelled from the query history view. [#1105](https://github.com/github/vscode-codeql/pull/1105)
## 1.5.10 - 25 January 2022
- Fix a bug where the results view moved column even when it was already visible. [#1070](https://github.com/github/vscode-codeql/pull/1070)
- Add packaging-related commands. _CodeQL: Download Packs_ downloads query packs from the package registry that can be run locally, and _CodeQL: Install Pack Dependencies_ installs dependencies for packs in your workspace. [#1076](https://github.com/github/vscode-codeql/pull/1076)
## 1.5.9 - 17 December 2021
- Avoid creating a third column when opening the results view. The results view will always open to the right of the active editor, unless the active editor is in the rightmost editor column. In that case open in the leftmost column. [#1037](https://github.com/github/vscode-codeql/pull/1037)
- Add a CodeLens to make the Quick Evaluation command more accessible. Click the `Quick Evaluation` prompt above a predicate definition in the editor to evaluate that predicate on its own. You can enable/disable this feature in the `codeQL.runningQueries.quickEvalCodelens` setting. [#1035](https://github.com/github/vscode-codeql/pull/1035) & [#1052](https://github.com/github/vscode-codeql/pull/1052)
- Fix a bug where the _Alerts_ option would show in the results view even if there is no alerts table available. [#1038](https://github.com/github/vscode-codeql/pull/1038)
## 1.5.8 - 2 December 2021
- Emit a more explicit error message when a user tries to add a database with an unzipped source folder to the workspace. [#1021](https://github.com/github/vscode-codeql/pull/1021)
- Ensure `src.zip` archives are used as the canonical source instead of `src` folders when importing databases. [#1025](https://github.com/github/vscode-codeql/pull/1025)
## 1.5.7 - 23 November 2021
- Fix the _CodeQL: Open Referenced File_ command for Windows systems. [#979](https://github.com/github/vscode-codeql/pull/979)
- Support large SARIF results files (>4GB) without crashing VS Code. [#1004](https://github.com/github/vscode-codeql/pull/1004)
- Fix a bug that shows 'Set current database' when hovering over the currently selected database in the databases view. [#976](https://github.com/github/vscode-codeql/pull/976)
- Fix a bug with importing large databases. Databases over 4GB can now be imported directly from LGTM or from a zip file. This functionality is only available when using CodeQL CLI version 2.6.0 or later. [#971](https://github.com/github/vscode-codeql/pull/971)
- Replace certain control codes (`U+0000` - `U+001F`) with their corresponding control labels (`U+2400` - `U+241F`) in the results view. [#963](https://github.com/github/vscode-codeql/pull/963)
- Allow case-insensitive project slugs for GitHub repositories when adding a CodeQL database from LGTM. [#978](https://github.com/github/vscode-codeql/pull/961)
- Add a _CodeQL: Preview Query Help_ command to generate Markdown previews of `.qhelp` query help files. This command should only be run in trusted workspaces. See [the CodeQL CLI docs](https://codeql.github.com/docs/codeql-cli/testing-query-help-files) for more information about query help. [#988](https://github.com/github/vscode-codeql/pull/988)
- Make "Open Referenced File" command accessible from the active editor menu. [#989](https://github.com/github/vscode-codeql/pull/989)
- Fix a bug where result set names in the result set drop-down were disappearing when viewing a sorted table. [#1007](https://github.com/github/vscode-codeql/pull/1007)
- Allow query result locations with 0 as the end column value. These are treated as the first column in the line. [#1002](https://github.com/github/vscode-codeql/pull/1002)
## 1.5.6 - 07 October 2021
- Add progress messages to LGTM download option. This makes the two-step process (selecting a project, then selecting a language) more clear. [#960](https://github.com/github/vscode-codeql/pull/960)
- Remove line about selecting a language from the dropdown when downloading database from LGTM. This makes the download progress visible when the popup is not expanded. [#957](https://github.com/github/vscode-codeql/pull/957)
- Fix a bug where copying the version information fails when a CodeQL CLI cannot be found. [#958](https://github.com/github/vscode-codeql/pull/958)
- Avoid a race condition when deleting databases that can cause occasional errors. [#959](https://github.com/github/vscode-codeql/pull/959)
- Fix bug where a query is sometimes run before the file is saved. [#947](https://github.com/github/vscode-codeql/pull/947)
- Fix broken contextual queries, including _View AST_. [#949](https://github.com/github/vscode-codeql/pull/949)
## 1.5.4 - 02 September 2021
- Add support for filename pattern in history view. [#930](https://github.com/github/vscode-codeql/pull/930)
- Add an option _View Results (CSV)_ to view the results of a non-alert query. The existing options for alert queries have been renamed to _View Alerts_ to avoid confusion. [#929](https://github.com/github/vscode-codeql/pull/929)
- Allow users to specify the number of paths to display for each alert. [#931](https://github.com/github/vscode-codeql/pull/931)
- Adjust pagination controls in _CodeQL Query Results_ to always be visible [#936](https://github.com/github/vscode-codeql/pull/936)
- Fix bug where _View AST_ fails due to recent refactoring in the standard library and query packs. [#939](https://github.com/github/vscode-codeql/pull/939)
## 1.5.3 - 18 August 2021
- Add a command _CodeQL: Run Query on Multiple Databases_, which lets users select multiple databases to run a query on. [#898](https://github.com/github/vscode-codeql/pull/898)
- Autodetect what language a query targets. This refines the _CodeQL: Run Query on Multiple Databases_ command to only show relevant databases. [#915](https://github.com/github/vscode-codeql/pull/915)
- Adjust test log output to display diffs only when comparing failed test results with expected test results. [#920](https://github.com/github/vscode-codeql/pull/920)
## 1.5.2 - 13 July 2021
- Add the _Add Database Source to Workspace_ command to the right-click context menu in the databases view. This lets users re-add a database's source folder to the workspace and browse the source code. [#891](https://github.com/github/vscode-codeql/pull/891)
- Fix markdown rendering in the description of the `codeQL.cli.executablePath` setting. [#908](https://github.com/github/vscode-codeql/pull/908)
- Fix the _Open Query Results_ command in the query history view. [#909](https://github.com/github/vscode-codeql/pull/909)
## 1.5.1 - 23 June 2021
No user facing changes.
## 1.5.0 - 14 June 2021
- Display CodeQL CLI version being downloaded during an upgrade. [#862](https://github.com/github/vscode-codeql/pull/862)
- Display a helpful message and link to documentation when a query produces no results. [#866](https://github.com/github/vscode-codeql/pull/866)
- Refresh test databases automatically after a test run. [#868](https://github.com/github/vscode-codeql/pull/868)
- Allow users to specify a custom directory for storing query server logs (`codeQL.runningQueries.customLogDirectory`). The extension will not delete these logs automatically. [#863](https://github.com/github/vscode-codeql/pull/863)
- Support the VS Code [Workspace Trust feature](https://code.visualstudio.com/docs/editor/workspace-trust). This extension is now enabled in untrusted workspaces, but it restricts commands that contain arbitrary paths. [#861](https://github.com/github/vscode-codeql/pull/861)
- Allow the `codeQL.cli.executablePath` configuration setting to be set in workspace-scoped configuration files. This means that each workspace can now specify its own CodeQL CLI compiler, a feature that is unblocked due to implementing Workspace Trust. [#861](https://github.com/github/vscode-codeql/pull/861)
## 1.4.8 - 05 May 2021
- Copy version information to the clipboard when a user clicks the CodeQL section of the status bar. [#845](https://github.com/github/vscode-codeql/pull/845)
- Ensure changes in directories that contain tests will be properly updated in the test explorer. [#846](https://github.com/github/vscode-codeql/pull/846)
- Remind users to choose a language when downloading a database from LGTM. [#852](https://github.com/github/vscode-codeql/pull/852)
## 1.4.7 - 23 April 2021
- Fix a bug that prevented the results view from being loaded. [#842](https://github.com/github/vscode-codeql/pull/842)
## 1.4.6 - 21 April 2021
- Avoid showing an error popup when running a query with `@kind table` metadata. [#814](https://github.com/github/vscode-codeql/pull/814)
- Add an option to jump from a .qlref file to the .ql file it references. [#815](https://github.com/github/vscode-codeql/pull/815)
- Avoid opening the results panel when a database is deleted. [#831](https://github.com/github/vscode-codeql/pull/831)
- Forward all query metadata to the CLI when interpreting results. [#838](https://github.com/github/vscode-codeql/pull/838)
## 1.4.5 - 22 March 2021
- Avoid showing an error popup when user runs a query without `@kind` metadata. [#801](https://github.com/github/vscode-codeql/pull/801)
- Fix running of tests when the `ms-python` extension is installed. [#803](https://github.com/github/vscode-codeql/pull/803)
## 1.4.4 - 19 March 2021
- Introduce evaluator options for saving intermediate results to the disk cache (`codeQL.runningQueries.saveCache`) and for limiting the size of this cache (`codeQL.runningQueries.cacheSize`). [#778](https://github.com/github/vscode-codeql/pull/778)
- Respect the `codeQL.runningQueries.numberOfThreads` setting when creating SARIF files during result interpretation. [#771](https://github.com/github/vscode-codeql/pull/771)
- Allow using raw LGTM project slugs for fetching LGTM databases. [#769](https://github.com/github/vscode-codeql/pull/769)
- Better error messages when BQRS interpretation fails to produce SARIF. [#770](https://github.com/github/vscode-codeql/pull/770)
- Implement sorting of the query history view by name, date, and results count. [#777](https://github.com/github/vscode-codeql/pull/777)
- Add a configuration option to pass additional arguments to the CLI when running tests. [#785](https://github.com/github/vscode-codeql/pull/785)
- Introduce option to view query results as CSV. [#784](https://github.com/github/vscode-codeql/pull/784)
- Add some snippets for commonly used QL statements. [#782](https://github.com/github/vscode-codeql/pull/782)
- More descriptive error messages on QL test failures. [#788](https://github.com/github/vscode-codeql/pull/788)
## 1.4.3 - 22 February 2021
- Avoid displaying an error when removing orphaned databases and the storage folder does not exist. [#748](https://github.com/github/vscode-codeql/pull/748)
- Add better error messages when AST Viewer is unable to create an AST. [#753](https://github.com/github/vscode-codeql/pull/753)
- Cache AST viewing operations so that subsequent calls to view the AST of a single file will be extremely fast. [#753](https://github.com/github/vscode-codeql/pull/753)
- Ensure CodeQL version in status bar updates correctly when version changes. [#754](https://github.com/github/vscode-codeql/pull/754)
- Avoid deleting the quick query file when it is re-opened. [#747](https://github.com/github/vscode-codeql/pull/747)
## 1.4.2 - 2 February 2021
- Add a status bar item for the CodeQL CLI to show the current version. [#741](https://github.com/github/vscode-codeql/pull/741)
- Fix version constraint for flagging CLI support of non-destructive updates. [#744](https://github.com/github/vscode-codeql/pull/744)
- Add a _More Information_ button in the telemetry popup that opens the [telemetry documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code) in a browser tab. [#742](https://github.com/github/vscode-codeql/pull/742)
## 1.4.1 - 29 January 2021
- Reword the telemetry modal dialog box. [#738](https://github.com/github/vscode-codeql/pull/738)
## 1.4.0 - 29 January 2021
- Fix bug where databases are not reregistered when the query server restarts. [#734](https://github.com/github/vscode-codeql/pull/734)
- Fix bug where upgrade requests were erroneously being marked as failed. [#734](https://github.com/github/vscode-codeql/pull/734)
- On a strictly opt-in basis, collect anonymized usage data from the VS Code extension, helping improve CodeQL's usability and performance. See the [telemetry documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code) for more information on exactly what data is collected and what it is used for. [#611](https://github.com/github/vscode-codeql/pull/611)
## 1.3.10 - 20 January 2021
- Include the full stack in error log messages to help with debugging. [#726](https://github.com/github/vscode-codeql/pull/726)
## 1.3.9 - 12 January 2021
- No changes visible to end users.
## 1.3.8 - 17 December 2020
- Ensure databases are unlocked when removing them from the workspace. This will ensure that after a database is removed from VS Code, queries can be run on it from the command line without restarting the IDE. Requires CodeQL CLI 2.4.1 or later. [#681](https://github.com/github/vscode-codeql/pull/681)
- Fix bug when removing databases where sometimes the source folder would not also be removed from the workspace or the database files would not be deleted from the workspace storage location. [#692](https://github.com/github/vscode-codeql/pull/692)
- Query results with no string representation will now be displayed with placeholder text in query results. Previously, they were omitted. [#694](https://github.com/github/vscode-codeql/pull/694)
- Add a label for the language of a database in the databases view. This will only take effect for new databases created with the CodeQL CLI v2.4.1 or later. [#697](https://github.com/github/vscode-codeql/pull/697)
- Add clearer error message when running a query using a missing or invalid qlpack. [#702](https://github.com/github/vscode-codeql/pull/702)
- Add clearer error message when trying to run a command from the query history view if no item in the history is selected. [#702](https://github.com/github/vscode-codeql/pull/702)
- Fix a bug where it is not possible to download some database archives. This fix specifically addresses large archives and archives whose central directories do not align with file headers. [#700](https://github.com/github/vscode-codeql/pull/700)
- Avoid error dialogs when QL test discovery or database cleanup encounters a missing directory. [#706](https://github.com/github/vscode-codeql/pull/706)
- Add descriptive text and a link in the results view. [#711](https://github.com/github/vscode-codeql/pull/711)
- Fix the _Set Label_ command in the query history view. [#710](https://github.com/github/vscode-codeql/pull/710)
- Add the _CodeQL: View AST_ command to the right-click context menu when a source file in a database source archive is open in the editor. [#712](https://github.com/github/vscode-codeql/pull/712)
## 1.3.7 - 24 November 2020
- Editors opened by navigating from the results view are no longer opened in _preview mode_. Now they are opened as a persistent editor. [#630](https://github.com/github/vscode-codeql/pull/630)
- When comparing the results of a failed QL test run and the `.expected` file does not exist, an empty `.expected` file is created and compared against the `.actual` file. [#669](https://github.com/github/vscode-codeql/pull/669)
- Alter structure of the _Test Explorer_ tree. It now follows the structure of the filesystem instead of the QL Packs. [#624](https://github.com/github/vscode-codeql/pull/624)
- Alter structure of the _Test Explorer_ tree. It now follows the structure of the filesystem instead of the QL Packs. [#624](https://github.com/github/vscode-codeql/pull/624)
- Add more structured output for tests. [#626](https://github.com/github/vscode-codeql/pull/626)
- Whenever the extension restarts, orphaned databases will be cleaned up. These are databases whose files are located inside of the extension's storage area, but are not imported into the workspace.
- After renaming a database, the database list is re-sorted. [#685](https://github.com/github/vscode-codeql/pull/685)
- Add a `codeQl.resultsDisplay.pageSize` setting to configure the number of results displayed in a single results view page. Increase the default page size from 100 to 200. [#686](https://github.com/github/vscode-codeql/pull/686)
- Update the AST Viewer to include edge labels (if available) in addition to the target node labels. So far, only C/C++ databases take advantage of this change. [#688](https://github.com/github/vscode-codeql/pull/688)
## 1.3.6 - 4 November 2020
- Fix URI encoding for databases that were created with special characters in their paths. [#648](https://github.com/github/vscode-codeql/pull/648)
- Disable CodeQL Test commands from the command palette [#667](https://github.com/github/vscode-codeql/pull/667)
- Fix display of booleans in results view. [#657](https://github.com/github/vscode-codeql/pull/657)
- Avoid recursive selection changes in AST Viewer. [#668](https://github.com/github/vscode-codeql/pull/668)
## 1.3.5 - 27 October 2020
- Fix a bug where archived source folders for databases were not showing any contents.
- Fix URI encoding for databases that were created with special characters in their paths.
## 1.3.4 - 22 October 2020
- Add friendly welcome message when the databases view is empty.
- Add open query, open results, and remove query commands in the query history view title bar.
- The maximum number of simultaneous queries launchable by the `CodeQL: Run Queries in Selected Files` command is now configurable by changing the `codeQL.runningQueries.maxQueries` setting.
- Allow simultaneously run queries to be canceled in a single-click.
- Prevent multiple upgrade dialogs from appearing when running simultaneous queries on upgradeable databases.
- Fix sorting of results. Some pages of results would have the wrong sort order and columns.
- Remember previous sort order when reloading query results.
- Fix proper escaping of backslashes in SARIF message strings.
- Allow setting `codeQL.runningQueries.numberOfThreads` and `codeQL.runningTests.numberOfThreads` to 0, (which is interpreted as 'use one thread per core on the machine').
- Clear the problems view of all CodeQL query results when a database is removed.
- Add a `View DIL` command on query history items. This opens a text editor containing the Datalog Intermediary Language representation of the compiled query.
- Remove feature flag for the AST Viewer. For more information on how to use the AST Viewer, [see the documentation](https://help.semmle.com/codeql/codeql-for-vscode/procedures/exploring-the-structure-of-your-source-code.html).
- The `codeQL.runningTests.numberOfThreads` setting is now used correctly when running tests.
- Alter structure of the _Test Explorer_ tree. It now follows the structure of the filesystem instead of the qlpacks.
- Ensure output of CodeQL test runs includes compilation error messages and test failure messages.
## 1.3.3 - 16 September 2020
- Fix display of raw results entities with label but no url.
- Fix bug where sort order is forgotten when changing raw results page.
- Avoid showing a location link in results view when a result item has an empty location.
## 1.3.2 - 12 August 2020
- Fix error with choosing qlpack search path.
- Fix pagination when there are no results.
- Suppress database downloaded from URL message when action canceled.
- Fix QL test discovery to avoid showing duplicate tests in the test explorer.
- Enable pagination of query results
- Add experimental AST Viewer for Go and C++. To enable, add `"codeQL.experimentalAstViewer": true` to the user settings file.
## 1.3.1 - 7 July 2020
- Fix unzipping of large files.
- Ensure compare order is consistent when selecting two queries to compare. The first query selected is always the _from_ query and the query selected later is always the _to_ query.
- Ensure added databases have zipped source locations for databases added as archives or downloaded from the internet.
- Fix bug where it is not possible to add databases starting with `db-*`.
- Change styling of pagination section of the results page.
- Fix display of query text for stored quick queries.
## 1.3.0 - 22 June 2020
- Report error when selecting invalid database.
- Add descriptive message for database archive import failure.
- Respect VS Code's i18n locale setting when formatting dates and sorting strings.
- Allow the opening of large SARIF files externally from VS Code.
- Add new 'CodeQL: Compare Query' command that shows the differences between two queries.
- Allow multiple items in the query history view to be removed in one operation.
- Allow multiple items in the databases view to be removed in one operation.
- Allow multiple items in the databases view to be upgraded in one operation.
- Allow multiple items in the databases view to have their external folders opened.
- Allow all selected queries to be run in one command from the file explorer.
## 1.2.2 - 8 June 2020
- Fix auto-indentation rules.
- Add ability to download platform-specific releases of the CodeQL CLI if they are available.
- Fix handling of downloading prerelease versions of the CodeQL CLI.
- Add pagination for displaying non-interpreted results.
## 1.2.1 - 29 May 2020
- Better formatting and autoindentation when adding QLDoc comments to `.ql` and `.qll` files.
This project is an extension for Visual Studio Code that adds rich language support for [CodeQL](https://help.semmle.com/codeql) and allows you to easily find problems in codebases. In particular, the extension:
This project is an extension for Visual Studio Code that adds rich language support for [CodeQL](https://codeql.github.com/docs/) and allows you to easily find problems in codebases. In particular, the extension:
- Enables you to use CodeQL to query databases generated from source code.
- Shows the flow of data through the results of path queries, which is essential for triaging security results.
- Provides an easy way to run queries from the large, open source repository of [CodeQL security queries](https://github.com/github/codeql).
- Adds IntelliSense to support you writing and editing your own CodeQL query and library files.
To see what has changed in the last few versions of the extension, see the [Changelog](https://github.com/github/vscode-codeql/blob/master/extensions/ql-vscode/CHANGELOG.md).
To see what has changed in the last few versions of the extension, see the [Changelog](https://github.com/github/vscode-codeql/blob/main/extensions/ql-vscode/CHANGELOG.md).
## Quick start overview
The information in this `README` file describes the quickest way to start using CodeQL.
For information about other configurations, see the separate [CodeQL help](https://help.semmle.com/codeql/codeql-for-vscode.html).
For information about other configurations, see the separate [CodeQL help](https://codeql.github.com/docs/codeql-for-visual-studio-code/).
### Quick start: Installing and configuring the extension
@@ -22,7 +22,7 @@ For information about other configurations, see the separate [CodeQL help](https
### Quick start: Using CodeQL
1. [Import a database from LGTM](#importing-a-database-from-lgtm).
1. [Import a database from GitHub](#importing-a-database-from-github).
1. [Run a query](#running-a-query).
---
@@ -40,9 +40,9 @@ The CodeQL extension requires a minimum of Visual Studio Code 1.39. Older versio
### Checking access to the CodeQL CLI
The extension uses the [CodeQL CLI](https://help.semmle.com/codeql/codeql-cli.html) to compile and run queries. The extension automatically manages access to the CLI for you by default (recommended). To check for updates to the CodeQL CLI, you can use the **CodeQL: Check for CLI Updates** command.
The extension uses the [CodeQL CLI](https://codeql.github.com/docs/codeql-cli/) to compile and run queries. The extension automatically manages access to the CLI for you by default (recommended). To check for updates to the CodeQL CLI, you can use the **CodeQL: Check for CLI Updates** command.
If you want to override the default behavior and use a CodeQL CLI that's already on your machine, see [Configuring access to the CodeQL CLI](https://help.semmle.com/codeql/codeql-for-vscode/procedures/setting-up.html#configuring-access-to-the-codeql-cli).
If you want to override the default behavior and use a CodeQL CLI that's already on your machine, see [Configuring access to the CodeQL CLI](https://codeql.github.com/docs/codeql-for-visual-studio-code/setting-up-codeql-in-visual-studio-code/#configuring-access-to-the-codeql-cli).
If you have any difficulty with CodeQL CLI access, see the **CodeQL Extension Log** in the **Output** view for any error messages.
@@ -52,7 +52,7 @@ When you're working with CodeQL, you need access to the standard CodeQL librarie
Initially, we recommend that you clone and use the ready-to-use [starter workspace](https://github.com/github/vscode-codeql-starter/).
This includes libraries and queries for the main supported languages, with folders set up ready for your custom queries. After cloning the workspace (use `git clone --recursive`), you can use it in the same way as any other VS Code workspace—with the added advantage that you can easily update the CodeQL libraries.
For information about configuring an existing workspace for CodeQL, [see the documentation](https://help.semmle.com/codeql/codeql-for-vscode/procedures/setting-up.html#updating-an-existing-workspace-for-codeql).
For information about configuring an existing workspace for CodeQL, [see the documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/setting-up-codeql-in-visual-studio-code/#updating-an-existing-workspace-for-codeql).
## Upgrading CodeQL standard libraries
@@ -73,18 +73,19 @@ If you're using your own clone of the CodeQL standard libraries, you can do a `g
You can find all the commands contributed by the extension in the Command Palette (**Ctrl+Shift+P** or **Cmd+Shift+P**) by typing `CodeQL`, many of them are also accessible through the interface, and via keyboard shortcuts.
### Importing a database from LGTM
### Importing a database from GitHub
While you can use the [CodeQL CLI to create your own databases](https://help.semmle.com/codeql/codeql-cli/procedures/create-codeql-database.html), the simplest way to start is by downloading a database from LGTM.com.
While you can use the [CodeQL CLI to create your own databases](https://codeql.github.com/docs/codeql-cli/creating-codeql-databases/), the simplest way to start is by downloading a database from GitHub.com.
1.Open [LGTM.com](https://lgtm.com/#explore) in your browser.
1.Search for a project you're interested in, for example [Apache Kafka](https://lgtm.com/projects/g/apache/kafka).
1.Copy the link to that project, for example `https://lgtm.com/projects/g/apache/kafka`.
1. In VS Code, open the Command Palette and choose the **CodeQL: Download Database from LGTM** command.
1.Find a project that you're interested in on GitHub.com, for example [Apache Kafka](https://github.com/apache/kafka).
1.Copy the link to that project, for example `https://github.com/apache/kafka`.
1.In VS Code, open the Command Palette and choose the **CodeQL: Download Database from GitHub** command.
1. Paste the link you copied earlier.
1. Select the language for the database you want to download (only required if the project has databases for multiple languages).
1. Once the CodeQL database has been imported, it is displayed in the Databases view.
For more information, see [Choosing a database](https://codeql.github.com/docs/codeql-for-visual-studio-code/analyzing-your-projects/#choosing-a-database) on codeql.github.com.
### Running a query
The instructions below assume that you're using the CodeQL starter workspace, or that you've added the CodeQL libraries and queries repository to your workspace.
@@ -98,15 +99,23 @@ When the results are ready, they're displayed in the CodeQL Query Results view.
If there are any problems running a query, a notification is displayed in the bottom right corner of the application. In addition to the error message, the notification includes details of how to fix the problem.
### Keyboad navigation
If you wish to navigate the query results from your keyboard, you can bind shortcuts to the **CodeQL: Navigate Up/Down/Left/Right in Result Viewer** commands.
## What next?
For more information about the CodeQL extension, [see the documentation](https://help.semmle.com/codeql/codeql-for-vscode.html). Otherwise, you could:
For more information about the CodeQL extension, [see the documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/). Otherwise, you could:
- [Create a database for a different codebase](https://help.semmle.com/codeql/codeql-cli/procedures/create-codeql-database.html).
- [Create a database for a different codebase](https://codeql.github.com/docs/codeql-cli/creating-codeql-databases/).
- [Try out variant analysis](https://help.semmle.com/QL/learn-ql/ql-training.html).
- [Learn more about CodeQL](https://help.semmle.com/QL/learn-ql/).
- [Learn more about CodeQL](https://codeql.github.com/docs/).
- [Read how security researchers use CodeQL to find CVEs](https://securitylab.github.com/research).
## License
The CodeQL extension for Visual Studio Code is [licensed](LICENSE.md) under the MIT License. The version of CodeQL used by the CodeQL extension is subject to the [GitHub CodeQL Terms & Conditions](https://securitylab.github.com/tools/codeql/license).
## Data and Telemetry
If you specifically opt-in to permit GitHub to do so, GitHub will collect usage data and metrics for the purposes of helping the core developers to improve the CodeQL extension for VS Code. This data will not be shared with any parties outside of GitHub. IP addresses and installation IDs will be retained for a maximum of 30 days. Anonymous data will be retained for a maximum of 180 days. For more information about telemetry, [see the documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code).
// Automatically clear mock calls, instances, contexts and results before every test
// clearMocks: true,
// Indicates whether the coverage information should be collected while executing the test
// collectCoverage: false,
// An array of glob patterns indicating a set of files for which coverage information should be collected
// collectCoverageFrom: undefined,
// The directory where Jest should output its coverage files
// coverageDirectory: undefined,
// An array of regexp pattern strings used to skip coverage collection
// coveragePathIgnorePatterns: [
// "/node_modules/"
// ],
// Indicates which provider should be used to instrument code for coverage
coverageProvider:'v8',
// A list of reporter names that Jest uses when writing coverage reports
// coverageReporters: [
// "json",
// "text",
// "lcov",
// "clover"
// ],
// An object that configures minimum threshold enforcement for coverage results
// coverageThreshold: undefined,
// A path to a custom dependency extractor
// dependencyExtractor: undefined,
// Make calling deprecated APIs throw helpful error messages
// errorOnDeprecated: false,
// The default configuration for fake timers
// fakeTimers: {
// "enableGlobally": false
// },
// Force coverage collection from ignored files using an array of glob patterns
// forceCoverageMatch: [],
// A path to a module which exports an async function that is triggered once before all test suites
// globalSetup: undefined,
// A path to a module which exports an async function that is triggered once after all test suites
// globalTeardown: undefined,
// A set of global variables that need to be available in all test environments
// globals: {},
// The maximum amount of workers used to run your tests. Can be specified as % or a number. E.g. maxWorkers: 10% will use 10% of your CPU amount + 1 as the maximum worker number. maxWorkers: 2 will use a maximum of 2 workers.
// maxWorkers: "50%",
// An array of directory names to be searched recursively up from the requiring module's location
// moduleDirectories: [
// "node_modules"
// ],
// An array of file extensions your modules use
moduleFileExtensions:[
'js',
'mjs',
'cjs',
'jsx',
'ts',
'tsx',
'json'
],
// A map from regular expressions to module names or to arrays of module names that allow to stub out resources with a single module
<pathd="M 35.300905,316.97546 H 93.308718 V 116.76062 L 30.203249,129.41687 V 97.07312 L 92.957155,84.41687 h 35.507815 v 232.55859 h 58.00781 v 29.88282 H 35.300905 Z"fill="#C5C5C5"/>
<pathd="M 35.300905,316.97546 H 93.308718 V 116.76062 L 30.203249,129.41687 V 97.07312 L 92.957155,84.41687 h 35.507815 v 232.55859 h 58.00781 v 29.88282 H 35.300905 Z"/>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
