We're still not verifying the actual object returned by JSON.parse so
this isn't any safer at runtime than using 'any', but it helps add more
static typing to the code calling readJsonlFile.
This endpoint actually has the correct type already. We could explicitly
declare it as
RestEndpointMethodTypes["codeScanning"]["listCodeqlDatabases"]["response"]["data"][0]
but this seems unnecessary given how ugly that type is. If we just do nothing
then typescript already computes the correct type for us.
In the new version of Floating UI, it corrects that the JSDOM click was
seen as a "mobile" click. Since [`focusItemOnOpen`](https://floating-ui.com/docs/useListNavigation#focusitemonopen)
is set to `auto`, this results in selecting the first option when the
suggest box was opened. Now that JSDOM is correctly detected as a keyboard
input device, it will not select the first option when the suggest box is
opened. The tests have been updated to account for this by always first
selecting the first option before accepting it.
This adds an `endpointType` property to method definitions since we
already have different endpoints (for example methods and modules in
Ruby) and it would be useful to make a distinction between these (it's
not possible to model a module as a source/sink/summary, but it should
be possible to model as a type).
This extracts all common functionality from the various model editor
suggest box components into a single component that can be shared by
the model editor suggest box components to make improvements easier.
The SARIF comparison code was comparing the index of the artifact
location, which is not useful for comparison and may differ between runs
of very similar queries. This adds a function to convert a SARIF result
to a canonical form, which removes the index from the artifact location.
This fixes parsing of access paths for Ruby methods that contain square
brackets, such as `Liquid::Context#[]`. The previous implementation
would incorrectly stop capturing at the `]` character, resulting in a
method name of `[` for an access path of `Method[[]].ReturnValue`. This
fixes it by switching to the shared access path parsing code, which
correctly handles square brackets.
This adds the ability for consumers of the suggest box to add
diagnostics to the suggest box. When a diagnostic is returned for a
value, the input will be shown with a red border.
The custom Jest test runner was originally written to install the
required extensions for the CLI integration tests. This is no longer
necessary as of https://github.com/github/vscode-codeql/pull/3232, so
we can remove all code that deals with downloading VS Code and
installing extensions. The download of VS Code will now be handled by
the base `VSCodeTestRunner`.
This adds some helper functions that will be used for a suggestion box
in the future. There is one helper function for highlighting part of a
text case-insensitively. Another helper function will try to find
followup options based on a list of tokens.
The tests for these functions use access paths as input, but these
functions are not intended to be specific to access paths. They can be
used for any list of options/string.
This adds functions for parsing and validating access paths to prepare
for future functionality where we're going to be parsing and validating
access paths.
This removes some ESLint rules that do not give any linting errors when
removing the rule overrides from the config file. This could be because
there are no instances of the rule being violated, or because the rule
is already disabled by some other configuration.
This also adds the script as a script in the `package.json` with the
naming such that `npm generate` will re-generate the Chromium version
file. This will ensure that the CI checks fail when the Chromium version
doesn't match the minimum supported VS Code version.
According to the DefinitelyTyped documentation, the patch version of
the type declaration package is unrelated to the library patch version.
Therefore, we should use an X-range for `@types/node` to allow
newer patch versions to be installed automatically.
This switches the view code from Webpack to ESBuild to unify the build
systems for the extension and view code. There are no changes in
behavior, except that some features are now not supported (like dynamic
require/import) and importing the `classnames` package fails. However,
these were really easy to fix and don't hinder the further development
of the view code, so I've just fixed those instances.
It seems like we had some rules that disabled rules of this plugin, but
we didn't actually have it installed. I've now installed it, used the
recommended configuration, and removed our own disable rules. I've fixed
any errors that this introduced.
The legacy result was populated based on information that is already
present in `CompletedQueryInfo` anyway. Old history items which only
have the legacy result populated have not been created for at least 30
days now since the legacy query runner hasn't been used for quite a
while now.
Since we're only supporting the new query server, we can remove the
`QueryRunner` abstraction and just use the `NewQueryRunner` as a
concrete `QueryRunner` without an abstract base class. This simplifies
the code of the query server and removes some unnecessary indirection.
This removes the use of the CLI `codeql resolve library-path` command to
detect the language of a query pack. Instead, it uses the `qlpack.yml`
file to determine the language. This is slightly less correct since it
only works for `codeql/${language}-all` dependencies, but it is much
faster and more reliable. It also doesn't result in the CLI server
restarting for invalid query packs (such as in the `github/codeql`
repository or in any workspaces containing it).
During the qltest discovery, we were recreating the watchers for qltests
on every file change. This was causing the watchers to be recreated
on each change, while there were no functional changes to the watchers
themselves.
This commit moves the creation of the watchers to the constructor of
the QLTestDiscovery class, and removes the creation of the watchers
from the discover() method. The behavior should be the same.
This switches the CodeQL CLI download to `yauzl` instead of `unzipper`.
There should be no changes in behavior. I tested this manually on
Insiders by removing the distribution directory and this successfully
downloaded and extracted the CLI.
The CodeQL CLI always supports the `database unbundle` command since
140d369098
so we can remove the fallback behavior.
There were some places which were not passing in the CodeQL CLI server,
but these always have access to the CLI server, so this just passes them
in.
The only change in behavior (in terms of the fallback behavior) is in
the `new-query.test.ts` test.
This fixes some incorrect model files on case-insensitive file systems
when the package names are the same but the capitalization is different.
For example, when there are two packages `Volo.Abp.TestApp.MongoDb` and
`Volo.Abp.TestApp.MongoDB`, there would be 1 model file for each
package. However, on case-insensitive file systems, the second file
would overwrite the first file. This results in missing models. This
fixes it by canonicalizing the filenames to lowercase and writing all
files with the same package name to the same file.
This fixes all violations that can be fixed by using
`npm run lint:markdown -- --fix`.
This also updates the markdownlint configuration to require dashes in
unstyled lists. This results in the least amount of changes to Markdown
files. The default setting results in rewriting the complete CHANGELOG
file.
This wires up the comparison of SARIF results in the compare view. It
uses the same diffing algorithm as the raw results, but it uses the
SARIF results instead of the raw results.
This moves reading of the result sets to the `compareResults` method
since raw result sets don't need to be read for interpreted results and
the `findResultSetsToCompare` method is shared between the two types
of results.
This adds the `alerts` result set to the compare view if an interpreted
result is available. This assumes that the user has opened the query
in the results view before opening the compare view. It will not
interpret the results if the interpreted results are not available.
This will avoid showing a query-server popup on hovers. When someone
does CTRL+hover on source code in a database archive, the definitions
provider is triggered. The first time this is run, there will be a query that
is invoked in order to find definitions. This can be a long process.
Previously, this query brought up a popup window that could be cancelled.
However, this is confusing users since the query is automatically cancelled
when the mouse hovers away from the element.
The downside of this PR is that even when find definitions is explicitly invoked,
(using F12), there will still be no hover.
I think this is an improvement, but I am happy to discuss if others disagree.
This upgrades this package to fix tests on Windows. It seems like the
extraction of the VS Code archive is failing, which is fixed in the
newest version.
This fixes the rendering of method names when either the type or method
name is empty. This can happen when the method is a not in a class or
when the method is a synthetic method and the properties actually apply
to the type.
This splits the compare view messages into two different messages. One
contains the metadata that doesn't change when the user selects a
different result set, and the other contains the actual results.
This changes the default result set that is selected in the compare view
to the same as the default result set in the results view. This will
select `#select` by default for most queries, rather than the first
result set, which could be `edges` or `nodes` for some queries.
The columns are part of the result, so they should be moved there. This
is in preparation of showing SARIF results in the same view, which don't
have columns.
This enables [the ESLint `curly` rule](https://eslint.org/docs/latest/rules/curly)
with its options set to `all`. This enforces curly braces around all
blocks, even single-line ones.
I've used `npm run lint -- --fix` to fix all occurences.
This preserves the focus on the results viewer when showing a location
to ensure that the user can navigate to the next result without having
to click or change the focus to the results viewer first. This allows
the user to quickly navigate through the results.
It seems like changes to the CLI path setting are not picked up by the
extension when it is already activated. This is probably because the
`workspace.onDidChangeConfiguration` event is not fired when the update
is made programmatically.
This fixes it by manually firing the event so that all listeners (CLI
server, query server, IDE server) can pick up the change.
This adds the option to download multiple databases from GitHub in the
initial GitHub database download prompt. The databases will be
downloaded concurrently.
Unfortunately it doesn't seem possible to change the "OK" text in the
quick pick to "Download", so I've left it as "OK" for now.
We want users to be able to download databases from private/internal
repositories without using canary mode. This will change the prompt to
ask for credentials in non-canary mode as well.
This switches the request to the GitHub API for listing CodeQL databases
from a custom request to the Octokit REST API. This allows us to be more
type-safe without introducing our own types.
The update to `@octokit/openapi-types` was necessary to have access to
the `commit_oid` field.
This adds a source property to the database item to store the source of
the database, for example GitHub or an internet URL. This will be used
to automatically check for updates to GitHub-downloaded databases in the
future.
This fixes the contextual queries when you are not in a workspace with
the submodule and do not have any downloaded packs in the package cache.
In that case, the contextual queries would fail because they weren't
able to determine which pack belonged to the database.
This fixes it by downloading the `codeql/${language}-all` pack in case
no dbscheme is found for the database. After the download is complete,
it will return the expected value for the qlpacks. This should work in
almost all cases (at least for standard languages).
Ruby keyword arguments are represented differently than positional
arguments in the MaD format: they are represented as `Method[key:]`. The
framework endpoints query also returns the name as `key:`, so we can
detect these and format them as such.
This moves the creation of possible method argument options from the
view to the languages. This allows differentiating between the
languages, for example by using `Argument[self]` for Ruby instead of
`Argument[this]`.
This adds support for modeling types. A MaD language can now optionally
define a `type` predicate. This allows internally propagating these
models. The UI will now simply show a label "type" for type models
without any way to edit these.
This removes the `disabled` prop from the `Dropdown` component. This is
already included in the default HTML props of the `select` component,
so it's not necessary to add it again.
This prevents the creation of duplicate query pack names when creating a
query in the following ways:
- When you have selected a folder, the query pack name will include the
name of the folder. This should prevent duplicate query pack names
when creating queries in different folders.
- When the folder name includes `codeql` or `queries`, we will not
add `codeql-extra-queries-` since that would be redundant.
- After generating the query pack name, we will resolve all qlpacks and
check if one with this name already exists. If it does, we will start
adding an index to the name until we find a unique name.
This will change the skeleton query wizard to detect existing query
packs when creating a skeleton query. This allows the user to create a
query in an existing query pack that is not named
`codeql-custom-queries-{language}`.
This fixes a bug where the method row would not scroll into view when
revealing a method. The problem was that the `DataGridRow` component
on which the `ref` was set is a `display: contents` element, which
does not have a visual representation in the DOM. Therefore, it wasn't
possible to scroll the method row into view. This fixes it by moving
the ref to the `DataGridCell` component of the first column, which is
a normal element.
We shouldn't be directly using the `extLogger` if we have access to the
app logger (either directly or by passing it in as a parameter). This
removes all imports of `extLogger` from the model editor directory.
This adds the ability to generate Ruby models from a database. It uses
the `GenerateModel.ql` query to do this. The query will essentially
return data in the data extensions format, so this will just parse it
and return it as `ModeledMethod` objects.
This adds the current version of the queries for Ruby to the model
editor included queries. This makes it work without needing to check out
a separate branch of the CodeQL repository/submodule. I've removed most
commented out code from the queries, but the other parts should match.
This only makes Ruby available in the model editor when the following
is set in the settings.json (workspace or user) file:
```json5
{
"codeQL.model.enableRuby": true,
}
```
Make the minimum changes necessary for prototype Ruby support in the
model editor.
This consists of:
- Reading/writing modelled methods from/to data extensions in the
dynamic languages format
- Special-casing Ruby in a few places where Java/C# was previously
assumed.
This will use the MaD's definition of a method signature when decoding
BQRS files. This will allow us to change the method signature definition
for dynamic languages.
Before, if you had selected a folder or file within for example
`codeql-custom-queries-java` and selected `java` as the language, it
would create a nested folder within `codeql-custom-queries-java` with
the name `codeql-custom-queries-java`. This is unexpected for the user,
who would expect a new query to be created within
`codeql-custom-queries-java`. This fixes that by checking for this
specific condition. It does not fix it for all scenarios, such as where
the selected file/folder is nested multiple levels deep within the
`codeql-custom-queries-java` folder.
This will change the behavior of the "Create new query" command to
create the new query in the same folder as the first selected item in
the queries panel. If no items are selected, the behavior is the same
as before.
I've used events to communicate the selection from the queries panel to
the local queries module. This is some more code and some extra
complexity, but it ensures that we don't have a dependency from the
local queries module to the queries panel module. This makes testing
easier.
This changes the skeleton query wizard to not prompt for database
download after creating a query by default. Instead, it will show a
message with a button to download a database which will launch the same
prompt.
This will change the "Create new query" command to use the selected
language when creating a new query. If no language is selected, it will
still prompt the user to pick a language.
When calling for example `showAndLogExceptionWithTelemetry`, the stack
trace would be sent to Application Insights, but there was no way to
see the stack trace from within VS Code. This will add the stack trace
to the log by returning it from `fullMessageWithStack` and using it in
the appropriate places.
It is possible to open the model editor without opening a folder, but
this gave an unhelpful error message. This commit adds a more helpful
error message.
When a local query fails (for example, if it is cancelled), it may still
have an evaluation log. We weren't generating evaluation log summaries
in these cases, so the options to view the summary text and to use the
evaluation log viewer would not be available. This fixes it by also
trying to generate the summary in the case of a failed query.
This will ensure that when "Show Evaluator Log (Raw JSON)" is used on a
cancelled query history item, we will still show it if it exists. This
changes the error messages on other cases to be more specific.
This will add the `QueryOutputDir` to the `InitialQueryInfo` and
populate it when creating a local query history item. This will allow us
to open the results directory or show the evaluator log without a
completed query.
This changes the usage data provider tree items to keep a reference to
the method and usage instead of only including their properties in the
tree item. This makes it easier to find the original method and usage
when revealing an item in the tree. It also removes the `getParent` call
in `getTreeItem`.
The main reason for this fix is to ensure
`codeQLModelEditor.jumpToMethod` gets the correct `usage` argument.
It received the tree item before, but now we can actually pass the
usage that was clicked on.
When the GitHub API returns an error for a missing default branch, we
will now show a custom error message. This custom error message includes
a link to the page to create the branch. The error is detected using the
`errors` field on the response that is now being returned.
This makes it possible to decode source maps containing references to
code that is not part of the extension. If it finds any such references,
it will simply not decode the source map and use the original stack
trace instead.
`logFileLocation` was not set after a query finishes running. I don't
know when this bug was introduced. I think it goes as far back as
the refactor to remove the old query server.
This creates new tree item types for methods and usages such that these
can contain references to their parent and children. This allows us to
easily find the parent of a usage and to find the children of a method.
This removes an expensive `find` call in `getParent`.
When opening a library group in the model editor, unmodeled methods
would always be marked as unsaved, even if there were no changes. This
was because the `ModelKindDropdown` component did not properly take into
account that the `kind` for an unmodeled method should be an empty
string. It would always try setting it to `undefined`, which would cause
the method to be marked as unsaved. This fixes it by checking if there
are valid kinds before setting the kind to the first one.
This improves the immutability of the modeling store state by using
TypeScript's readonly types to ensure that state can only be modified
from within the modeling store or when it's copied. This mostly consists
of adding `readonly` to properties and arrays, but this also adds a
`DeepReadonly` type to use in `postMessage` arguments to ensure that
readonly objects can be passed in. `postMessage` will never modify the
objects, so this is safe.
The purpose of this change is to add a command that clears the cache except for predicates marked `cached`.
In contrast, the existing "VSCode: Clear Cache" command clears everything (`--mode=brutal`).
This calls into the query server's `evaluation/trimCache` method;
however, its existing behaviour is to do a database cleanup with `--mode=gentle`.
This is not well documented, and `--mode=normal` would give the desired behaviour.
Accordingly, this approach is dependent on separately changing the backend behaviour to `--mode=normal`.
Other possible amendments to this commit would be to not touch the legacy client
(replacing required methods by failing promises, since the legacy server is fully deprecated already),
or to have less duplication (by introducing more arguments — however,
I'm applying the rule of thumb that >3 copy-pastes are required for the introduction of a deduplicating abstraction).
This fixes a bug where the validation of modeled methods would not
consider the kind of the modeled method, and would therefore give an
error when there was e.g. a neutral sink and a non-neutral summary.
When using the "CodeQL: Install pack dependencies" command, we would
show packs that are located in the package cache or distribution. Since
there are no dependencies to install for these packs, these options are
not useful.
This will filter out any packs that are not in the workspace folders
when showing the quick pick. This should exclude most packs if you are
in a workspace without the `codeql` submodule and should be a lot more
intuitive in those cases. If you are in a workspace with the `codeql`
submodule, it will still show all the packs.
This will change the add button in the method modeling panel to only be
disabled if there is exactly 1 unmodeled method and there are no
unmodeled methods. This should be more intuitive for users since they
are able to see in 1 screen that there is an unmodeled method.
This will respect the user's `saveBeforeStart` setting when running a
variant analysis. This re-uses the existing `saveBeforeStart` function
that is used when running local queries. The default behavior if the
setting is not set is to save all open named files.
This sorts the methods in the methods usages panel the same as in the
model editor. Since this is dependent on the mode, we need to keep track
of the mode in the modeling store, so this also adds a mode field to the
db state.
This fixes three bugs related to the modeling store and view states:
- In the model editor view, when `setModeledMethods` was called, it
would do it on the active database, instead of the database that the
view was showing. This should not result in any visible bugs since the
active database is always the one that is being shown (in theory), but
I can imagine that it could cause issues if showing multiple model
editors next to each other.
- In the method modeling panel, the "reveal in editor" button would
always show the already active model editor. Therefore, if you had
multiple open and were still viewing the method of the first one, it
would always show the second one.
- In the method modeling panel, the same bug would cause the incorrect
modeled methods to be updated.
When selecting a method that has no modeled methods, the modeling state
would not contain an entry for the method signature. This would cause
the `modeledMethods` to be `undefined`, which is not allowed according
to its type.
This change sets the `fullMessage` of the
`showAndLogExceptionWithTelemetry` to include the stack trace. This
makes it possible to find the source of the error rather than only
knowing that a specific error occurred. If the error does not have a
stack trace (which should be rare) the message will be the same as
before.
This converts all remaining extension host code to handle multiple
models per method. The only place where we're using the legacy format
is in the webview and in the boundary between the webview and the
extension host.
This switches all places where we're retrieving some model configuration
to use the `ModelConfig` or `ModelConfigListener` types. This makes it
much easier to mock these settings in tests.
This also adds a listener to the `ModelEditorView` to send the new view
state when any of the settings is changed. This should make it easier
to test settings changes in the model editor without having to re-open
the model editor.
This updates the method modeling panel's view state when the
`codeQL.model.showMultipleModels` setting changes. This will ensure that
the setting updates without needing to restart VS Code since this view
is much harder to restart than the model editor.
This adds a view state to the method modeling panel similar to the
model editor. This will be used to send the state of the show multiple
models feature flag to the webview so this can be used to selectively
show/hide components in the method modeling panel.
This will change the input/output types for modeled methods in the
`modeled-method-fs.ts` file to take in multiple models per method. This
removes the need for conversion functions between this file and
`yaml.ts` files. Instead, the conversion functions are done when calling
any functions defined in `modeled-method-fs.ts` files.
This changes YAML parsing/creating functions for the model editor to
handle multiple models per method. The changes in the actual YAML
handling are fairly small because the format itself already supports
multiple models per method.
I've introduced a few helper functions to convert between the old and
new types. This should only be necessary while we're in the middle of
the transition to the new types and can be removed later. For now,
we'll just take the first model in the array when converting from the
new to the old type. This is a change in the behavior since currently
we always take the last model in the array but this behavior is
undocumented and unsupported, so it should be fine to change it.
Use it for `MultiCancellationToken`. And ensure that adding a
cancellation requested listener to the `MultiCancellationToken` will
forward any cancellation requests to all constituent tokens.
This will reveal a method for which "Review in editor" is clicked in the
model editor view: it will expand the group (library/package) in which
the method is located, scroll to the method, and highlight the method.
If the user clicks anywhere on the page, the highlight will be removed,
but the group will remain expanded.
This will call a method on the correct model editor view when the user
clicks on "Review in editor". This does not yet do anything to the view;
this will be added in a follow-up commit.
This is used for registering which model editor views are currently
active. This will be used to determine which view to send the "reveal
method" command to. It can also be used in the future to limit the
number of instances of the model editor that can be opened for a
database.
This uses the same pattern as variant analyses with a separate interface
for the view to avoid having circular dependencies.
This is a cancellation token that cancels when any of its constituent
cancellation tokens are cancelled.
This token is used to fix a bug in Find Definitions. Previously, when
clicking `CTRL` (or `CMD` on macs) inside a source file in an archive
and hovering over a token, this will automatically invoke the
definitions finder (in preparation for navigating to the definition).
The only way to cancel is to move down to the message popup and click
cancel there.
However, this is a bug. What _should_ happen is that if a user moves
their mouse away from the token, the operation should cancel.
The underlying problem is that the extension was only listening to the
cancellation token from inside `getLocationsForUriString` the
cancellation token used by the Language Server protocol to cancel
operations in flight was being ignored.
This fix will ensure we are listening to _both_ cancellation tokens
and cancel the query if either are cancelled.
This will change the `AbstractWebview` to dispose its tracked objects
(using `this.push`) when the panel is disposed rather than when the
view is disposed. This makes `this.push` actually useful in a view.
Before, the objects would only get disposed when the extension itself
was disposed.
Previously, if there was an explicit restart of the query server (eg-
by changing a configuration setting), then the query server process
would be started twice: once by the `close` handler and once by the
restart command.
By adding the `removeAllListeners` to the dispose method, we ensure that
when the query server shuts down gracefully, there won't be a `close`
listener that is going to restart it a second time if there is a
different way of restarting it.
It seems like Node's native `fetch` implementation isn't quite working
right with Octokit and MSW. This switches to using `node-fetch` like
we're already doing for all other requests (e.g. downloading databases).
This updates the model editor queries to the version that will be merged
into the CodeQL repository. There are some slight changes to the output
format, so we slightly need to change the BQRS decoding of those
queries.
The queries themselves were copied from the two PRs with some minor
additions at the end since these were changes in core CodeQL library
files.
After the upgrade to the correct types for js-yaml, the return type
of `load` is correctly typed as `unknown`. This means that we can't
use the return value directly, but need to validate it first.
This adds such validation by generating a JSON schema for a newly
created typed. The JSON schema generation is very similar to how we do
it in https://github.com/github/codeql-variant-analysis-action.
@@ -22,12 +22,12 @@ Please note that this project is released with a [Contributor Code of Conduct][c
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
* 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](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- 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](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
## Setting up a local build
@@ -99,6 +99,6 @@ More information about Storybook can be found inside the **Overview** page once
## Resources
* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
@@ -6,28 +6,21 @@ The extension is released. You can download it from the [Visual Studio Marketpla
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)
[](https://github.com/github/vscode-codeql/actions?query=workflow%3A%22Build+Extension%22+branch%3Amain)
* Enables you to use CodeQL to query databases and discover problems in codebases.
* 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.
* Supports you running CodeQL queries against thousands of repositories on GitHub using multi-repository variant analysis.
- Enables you to use CodeQL to query databases and discover problems in codebases.
- 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.
- Supports you running CodeQL queries against thousands of repositories on GitHub using multi-repository variant analysis.
## Project goals and scope
This project will track new feature development in CodeQL and, whenever appropriate, bring that functionality to the Visual Studio Code experience.
## Dependencies
This extension depends on the following two extensions for required functionality. They will be installed automatically when you install VS Code CodeQL.
The CodeQL for VS Code extension defines the version of Node.js that it is intended to run with. This Node.js version is used when running most CI and unit tests.
When running in production (i.e. as an extension for a VS Code application) it will use the Node.js version provided by VS Code. This can mean a different Node.js version is used by different users with different versions of VS Code.
We should make sure the CodeQL for VS Code extension works with the Node.js version supplied by all versions of VS Code that we support.
## Checking the version of Node.js supplied by VS Code
You can find this info by selecting "About Visual Studio Code" from the top menu.
## Updating the Node.js version
To update the Node.js version, run:
```bash
npx ts-node scripts/update-node-version.ts
```
## Node.js version used in tests
Unit tests will use whatever version of Node.js is installed locally. In CI this will be the version specified in the workflow.
Integration tests download a copy of VS Code and then will use whatever version of Node.js is provided by VS Code. See [VS Code version used in tests](./vscode-version.md#vs-code-version-used-in-tests) for more information.
1.Run the ["Run CLI tests" workflow](https://github.com/github/vscode-codeql/actions/workflows/cli-test.yml) and make sure the tests are green. If there were no merges between the time the workflow ran (it runs daily), and the release, you can skip this step.
1.Determine the new version number. We default to increasing the patch version number, but make our own judgement about whether a change is big enough to warrant a minor version bump. Common reasons for a minor bump could include:
- Making substantial new features available to all users. This can include lifting a feature flag.
- Breakage in compatibility with recent versions of the CLI.
- Minimum required version of VS Code is increased.
- New telemetry events are added.
- Deprecation or removal of commands.
- Accumulation of many changes, none of which are individually big enough to warrant a minor bump, but which together are. This does not include changes which are purely internal to the extension, such as refactoring, or which are only available behind a feature flag.
1. Create a release branch named after the new version (e.g. `v1.3.6`):
- For a regular scheduled release this branch will be based on latest `main`.
- Make sure your local copy of `main` is up to date so you are including all changes.
- To do a minimal bug-fix release, base the release branch on the tag from the most recent release and then add only the changes you want to release.
- Choose this option if you want to release a specific set of changes (e.g. a bug fix) and don't want to incur extra risk by including other changes that have been merged to the `main` branch.
1. Run the ["Run CLI tests" workflow](https://github.com/github/vscode-codeql/actions/workflows/cli-test.yml) and make sure the tests are green.
- You can skip this step if you are releasing from `main` and there were no merges since the most recent daily scheduled run of this workflow.
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.
* For picking the new version number, we default to increasing the patch version number, but make our own judgement about whether a change is big enough to warrant a minor version bump. Common reasons for a minor bump could include:
* Making substantial new features available to all users. This can include lifting a feature flag.
* Breakage in compatibility with recent versions of the CLI.
* Minimum required version of VS Code is increased.
* New telemetry events are added.
* Deprecation or removal of commands.
* Accumulation of many changes, none of which are individually big enough to warrant a minor bump, but which together are. This does not include changes which are purely internal to the extension, such as refactoring, or which are only available behind a feature flag.
1. Double-check that the node version we're using matches the one used for VS Code. You can find this info by seleting "About Visual Studio Code" from the top menu. If it doesn't match, 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
- Go through PRs that have been merged since the previous release 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 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, 2 and 3. 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` branch and pull latest changes
1. Lock the `main` branch.
* Go to the [branch protection rules for the `main` branch](https://github.com/github/vscode-codeql/settings/branch_protection_rules/16447115)
* Select "Lock branch"
* Click "Save changes"
1. Ensure that no PRs have been merged since the release PR that you merged. If there were, you might need to unlock `main` temporarily and update the CHANGELOG again.
1. Build the extension `npm run build` and install it on your VS Code using "Install from VSIX".
1. Commit any changes made during steps 4 and 5 with a commit message the same as the branch name (e.g. `v1.3.6`).
1. Open a PR for this release.
- The PR diff should contain:
- Any missing bits from steps 4 and 5. Most of the time, this will just be updating `CHANGELOG.md` with today's date.
- If releasing from a branch other than `main`, this PR will also contain the extension changes being released.
1. Build the extension using `npm run build` and install it on your VS Code using "Install from VSIX".
1. Go through [our test plan](./test-plan.md) to ensure that the extension is working as expected.
1. Switch to `main` and add a new tag on the `main` branch with your new version (named after the release), e.g.
1. Create a new tag on the release 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. Unlock the main branch
* Go to the [branch protection rules for the `main` branch](https://github.com/github/vscode-codeql/settings/branch_protection_rules/16447115)
* Deselect "Lock branch"
* Click "Save changes"
1. Merge the release PR into `main`.
- If there are conflicts in the changelog, make sure to place any new changelog entries at the top, above the section for the current release, as these new entries are not part of the current release and should be placed in the "unreleased" section.
- The release PR must be merged before pushing the tag to ensure that we always release a commit that is present on the `main` branch. It's not required that the commit is the head of the `main` branch, but there should be no chance of a future release accidentally not including changes from this release.
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. Find the [Release](https://github.com/github/vscode-codeql/actions?query=workflow%3ARelease) workflow run that was just triggered by pushing the tag, and monitor the status of the release build.
- 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. 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. 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. Approve the deployments of the [Release](https://github.com/github/vscode-codeql/actions?query=workflow%3ARelease) workflow run. This will automatically publish to Open VSX and VS Code Marketplace.
- If there is an authentication failure when publishing, be sure to check that the authentication keys haven't expired. See below.
1. Go to the draft GitHub release in [the releases page](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.
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.
1. Review and merge the version bump PR that is automatically created by the Release workflow.
* Unit tests: these live in the `tests/unit-tests/` directory
* View tests: these live in `src/view/variant-analysis/__tests__/`
* VSCode integration tests:
*`test/vscode-tests/activated-extension` tests: These are intended to cover functionality that require the full extension to be activated but don't require the CLI. This suite is not run against multiple versions of the CLI in CI.
*`test/vscode-tests/no-workspace` tests: These are intended to cover functionality around not having a workspace. The extension is not activated in these tests.
*`test/vscode-tests/minimal-workspace` tests: These are intended to cover functionality that need a workspace but don't require the full extension to be activated.
* CLI integration tests: these live in `test/vscode-tests/cli-integration`
* These tests are intended to cover functionality that is related to the integration between the CodeQL CLI and the extension. These tests are run against each supported versions of the CLI in CI.
- Unit tests: these live in the `tests/unit-tests/` directory
- View tests: these live in `src/view/variant-analysis/__tests__/`
- VSCode integration tests:
-`test/vscode-tests/activated-extension` tests: These are intended to cover functionality that require the full extension to be activated but don't require the CLI. This suite is not run against multiple versions of the CLI in CI.
-`test/vscode-tests/no-workspace` tests: These are intended to cover functionality around not having a workspace. The extension is not activated in these tests.
-`test/vscode-tests/minimal-workspace` tests: These are intended to cover functionality that need a workspace but don't require the full extension to be activated.
- CLI integration tests: these live in `test/vscode-tests/cli-integration`
- These tests are intended to cover functionality that is related to the integration between the CodeQL CLI and the extension. These tests are run against each supported versions of the CLI in CI.
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.
@@ -26,9 +26,9 @@ Pre-requisites:
Then, from the `extensions/ql-vscode` directory, use the appropriate command to run the tests:
* Unit tests: `npm run test:unit`
* View Tests: `npm test:view`
* VSCode integration tests: `npm run test:vscode-integration`
- Unit tests: `npm run test:unit`
- View Tests: `npm run test:view`
- VSCode integration tests: `npm run test:vscode-integration`
#### Running CLI integration tests from the terminal
@@ -48,9 +48,9 @@ Alternatively, you can run the tests inside of VSCode. There are several VSCode
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
- Unit tests: run the _Launch Unit Tests_ task
- View Tests: run the _Launch Unit Tests - React_ task
- VSCode integration tests: run the _Launch Unit Tests - No Workspace_ and _Launch Unit Tests - Minimal Workspace_ tasks
The CodeQL for VS Code extension specifies the versions of VS Code that it is compatible with. VS Code will only offer to install and upgrade the extension when this version range is satisfied.
## Where is the VS Code version specified
1. Hard limit in [`package.json`](https://github.com/github/vscode-codeql/blob/606bfd7f877d9fffe4ff83b78015ab15f8840b12/extensions/ql-vscode/package.json#L16)
This is the value that VS Code understands and respects. If a user does not meet this version requirement then VS Code will not offer to install the CodeQL for VS Code extension, and if the extension is already installed then it will silently refuse to upgrade the extension.
1. Soft limit in [`extension.ts`](https://github.com/github/vscode-codeql/blob/606bfd7f877d9fffe4ff83b78015ab15f8840b12/extensions/ql-vscode/src/extension.ts#L307)
This value is used internally by the CodeQL for VS Code extension and is used to provide a warning to users without blocking them from installing or upgrading. If the extension detects that this version range is not met it will output a warning message to the user prompting them to upgrade their VS Code version to ge the latest features of CodeQL.
## When to update the VS Code version
Generally we should aim to support as wide a range of VS Code versions as we can, so unless there is a reason to do so we do not update the minimum VS Code version requirement.
Reasons for updating the minimum VS Code version include:
- A new feature is included in VS Code. We may want to ensure that it is available to use so we do not have to provide an alternative code path.
- A breaking change has happened in VS Code, and it is not possible to support both new and old versions.
Also consider what percentage of our users are using each VS Code version. This information is available in our telemetry.
## How to update the VS Code version
To provide a good experience to users, it is recommented to update the `MIN_VERSION` in `extension.ts` first and release, and then update the `vscode` version in `package.json` and release again.
By staggering this update across two releases it gives users on older VS Code versions a chance to upgrade before it silently refuses to upgrade them.
After updating the minimum version in `package.json`, make sure to also run the following command to update any generated
files dependent on this version:
```bash
npm run generate
```
## VS Code version used in tests
The integration tests use the latest stable version of VS Code. This is specified in
the [`test/vscode-tests/jest-runner-vscode.config.base.js`](https://github.com/github/vscode-codeql/blob/main/extensions/ql-vscode/test/vscode-tests/jest-runner-vscode.config.base.js#L15)
file. This shouldn't need to be updated unless there is a breaking change in VS Code that prevents the tests from running.
- Update variant analysis view to show when cancelation is in progress. [#3405](https://github.com/github/vscode-codeql/pull/3405)
- Remove support for CodeQL CLI versions older than 2.13.5. [#3371](https://github.com/github/vscode-codeql/pull/3371)
- Add a timeout to downloading databases and the CodeQL CLI. These can be changed using the `codeQL.addingDatabases.downloadTimeout` and `codeQL.cli.downloadTimeout` settings respectively. [#3373](https://github.com/github/vscode-codeql/pull/3373)
## 1.12.2 - 14 February 2024
- Stop allowing running variant analyses with a query outside of the workspace. [#3302](https://github.com/github/vscode-codeql/pull/3302)
## 1.12.1 - 31 January 2024
- Enable collection of telemetry for the `codeQL.addingDatabases.addDatabaseSourceToWorkspace` setting. [#3238](https://github.com/github/vscode-codeql/pull/3238)
- In the CodeQL model editor, you can now select individual method rows and save changes to only the selected rows, instead of having to save the entire library model. [#3156](https://github.com/github/vscode-codeql/pull/3156)
- If you run a query without having selected a database, we show a more intuitive prompt to help you select a database. [#3214](https://github.com/github/vscode-codeql/pull/3214)
- Error messages returned from the CodeQL CLI are now less verbose and more user-friendly. [#3259](https://github.com/github/vscode-codeql/pull/3259)
- The UI for browsing and running CodeQL tests has moved to use VS Code's built-in test UI. This makes the CodeQL test UI more consistent with the test UIs for other languages.
This change means that this extension no longer depends on the "Test Explorer UI" and "Test Adapter Converter" extensions. You can uninstall those two extensions if they are
not being used by any other extensions you may have installed. [#3232](https://github.com/github/vscode-codeql/pull/3232)
## 1.12.0 - 11 January 2024
- Add a prompt for downloading a GitHub database when opening a GitHub repository. [#3138](https://github.com/github/vscode-codeql/pull/3138)
- Avoid showing a popup when hovering over source elements in database source files. [#3125](https://github.com/github/vscode-codeql/pull/3125)
- Add comparison of alerts when comparing query results. This allows viewing path explanations for differences in alerts. [#3113](https://github.com/github/vscode-codeql/pull/3113)
- Fix a bug where the CodeQL CLI and variant analysis results were corrupted after extraction in VS Code Insiders. [#3151](https://github.com/github/vscode-codeql/pull/3151) & [#3152](https://github.com/github/vscode-codeql/pull/3152)
- Show progress when extracting the CodeQL CLI distribution during installation. [#3157](https://github.com/github/vscode-codeql/pull/3157)
- Add option to cancel opening the model editor. [#3189](https://github.com/github/vscode-codeql/pull/3189)
## 1.11.0 - 13 December 2023
- Add a new method modeling panel to classify methods as sources/sinks/summaries while in the context of the source code. [#3128](https://github.com/github/vscode-codeql/pull/3128)
- Adds the ability to add multiple classifications per method in the CodeQL Model Editor. [#3128](https://github.com/github/vscode-codeql/pull/3128)
- Switch add and delete button positions in the CodeQL Model Editor. [#3123](https://github.com/github/vscode-codeql/pull/3123)
- Add a prompt to the "Quick query" command to encourage users in single-folder workspaces to use "Create query" instead. [#3082](https://github.com/github/vscode-codeql/pull/3082)
- Remove support for CodeQL CLI versions older than 2.11.6. [#3087](https://github.com/github/vscode-codeql/pull/3087)
- Preserve focus on results viewer when showing a location in a file. [#3088](https://github.com/github/vscode-codeql/pull/3088)
- The `dataflowtracking` and `tainttracking` snippets expand to the new module-based interface. [#3091](https://github.com/github/vscode-codeql/pull/3091)
- The compare view will now show a loading message while the results are loading. [#3107](https://github.com/github/vscode-codeql/pull/3107)
- Make top-banner of the model editor sticky [#3120](https://github.com/github/vscode-codeql/pull/3120)
## 1.10.0 - 16 November 2023
- Add new CodeQL views for managing databases and queries:
1. A queries panel that shows all queries in your workspace. It allows you to view, create, and run queries in one place.
2. A language selector, which allows you to quickly filter databases and queries by language.
For more information, see the [documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/analyzing-your-projects/#filtering-databases-and-queries-by-language).
- When adding a CodeQL database, we no longer add the database source folder to the workspace by default (since this caused bugs in single-folder workspaces). [#3047](https://github.com/github/vscode-codeql/pull/3047)
- You can manually add individual database source folders to the workspace with the "Add Database Source to Workspace" right-click command in the databases view.
- To restore the old behavior of adding all database source folders by default, set the `codeQL.addingDatabases.addDatabaseSourceToWorkspace` setting to `true`.
- Rename the `codeQL.databaseDownload.allowHttp` setting to `codeQL.addingDatabases.allowHttp`, so that database-related settings are grouped together in the Settings UI. [#3047](https://github.com/github/vscode-codeql/pull/3047) & [#3069](https://github.com/github/vscode-codeql/pull/3069)
- The "Sort by Language" action in the databases view now sorts by name within each language. [#3055](https://github.com/github/vscode-codeql/pull/3055)
## 1.9.4 - 6 November 2023
No user facing changes.
## 1.9.3 - 26 October 2023
- Sorted result set filenames now include a hash of the result set name instead of the full name. [#2955](https://github.com/github/vscode-codeql/pull/2955)
- The "Install Pack Dependencies" will now only list CodeQL packs located in the workspace. [#2960](https://github.com/github/vscode-codeql/pull/2960)
- Fix a bug where the "View Query Log" action for a query history item was not working. [#2984](https://github.com/github/vscode-codeql/pull/2984)
- Add a command to sort items in the databases view by language. [#2993](https://github.com/github/vscode-codeql/pull/2993)
- Fix not being able to open the results directory or evaluator log for a cancelled local query run. [#2996](https://github.com/github/vscode-codeql/pull/2996)
- Fix empty row in alert path when the SARIF location was empty. [#3018](https://github.com/github/vscode-codeql/pull/3018)
## 1.9.2 - 12 October 2023
- Fix a bug where the query to Find Definitions in database source files would not be cancelled appropriately. [#2885](https://github.com/github/vscode-codeql/pull/2885)
- It is now possible to show the language of query history items using the `%l` specifier in the `codeQL.queryHistory.format` setting. Note that this only works for queries run after this upgrade, and older items will show `unknown` as a language. [#2892](https://github.com/github/vscode-codeql/pull/2892)
- Increase the required version of VS Code to 1.82.0. [#2877](https://github.com/github/vscode-codeql/pull/2877)
- Fix a bug where the query server was restarted twice after configuration changes. [#2884](https://github.com/github/vscode-codeql/pull/2884).
- Add support for the `telemetry.telemetryLevel` setting. For more information, see the [telemetry documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code). [#2824](https://github.com/github/vscode-codeql/pull/2824).
- Add a "CodeQL: Trim Cache" command that clears the evaluation cache of a database except for predicates annotated with the `cached` keyword. Its purpose is to get accurate performance measurements when tuning the final stage of a query, like a data-flow configuration. This is equivalent to the `codeql database cleanup --mode=normal` CLI command. In contrast, the existing "CodeQL: Clear Cache" command clears the entire cache. CodeQL CLI v2.15.1 or later is required. [#2928](https://github.com/github/vscode-codeql/pull/2928)
- Fix syntax highlighting directly after import statements with instantiation arguments. [#2792](https://github.com/github/vscode-codeql/pull/2792)
- The `debug.saveBeforeStart` setting is now respected when running variant analyses. [#2950](https://github.com/github/vscode-codeql/pull/2950)
- The 'open database' button of the model editor was renamed to 'open source'. Also, it's now only available if the source archive is available as a workspace folder. [#2945](https://github.com/github/vscode-codeql/pull/2945)
## 1.9.1 - 29 September 2023
- Add warning when using a VS Code version older than 1.82.0. [#2854](https://github.com/github/vscode-codeql/pull/2854)
- Fix a bug when parsing large evaluation log summaries. [#2858](https://github.com/github/vscode-codeql/pull/2858)
- Right-align and format numbers in raw result tables. [#2864](https://github.com/github/vscode-codeql/pull/2864)
- Remove rate limit warning notifications when using Code Search to add repositories to a variant analysis list. [#2812](https://github.com/github/vscode-codeql/pull/2812)
## 1.9.0 - 19 September 2023
- Release the [CodeQL model editor](https://codeql.github.com/docs/codeql-for-visual-studio-code/using-the-codeql-model-editor/) to create CodeQL model packs for Java frameworks. Open the editor using the "CodeQL: Open CodeQL Model Editor (Beta)" command. [#2823](https://github.com/github/vscode-codeql/pull/2823)
## 1.8.12 - 11 September 2023
- Fix a bug where variant analysis queries would fail for queries in the `codeql/java-queries` query pack. [#2786](https://github.com/github/vscode-codeql/pull/2786)
@@ -17,8 +17,6 @@ For information about other configurations, see the separate [CodeQL help](https
### Quick start: Installing and configuring the extension
1. [Install the extension](#installing-the-extension).
*Note: vscode-codeql installs the following dependencies for required functionality: [Test Adapter Converter](https://marketplace.visualstudio.com/items?itemName=ms-vscode.test-adapter-converter), [Test Explorer UI](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer).*
1. [Check access to the CodeQL CLI](#checking-access-to-the-codeql-cli).
1. [Clone the CodeQL starter workspace](#cloning-the-codeql-starter-workspace).
"description":"Names of extension packs to include in the evaluation. These are resolved from the locations specified in `additionalPacks`."
},
"additionalRunQueryArgs":{
"type":"object",
"description":"**Internal use only**. Additional arguments to pass to the `runQuery` command of the query server, without validation."
}
}
}
@@ -193,6 +178,11 @@
"type":"string",
"default":"",
"markdownDescription":"Path to the CodeQL executable that should be used by the CodeQL extension. The executable is named `codeql` on Linux/Mac and `codeql.exe` on Windows. If empty, the extension will look for a CodeQL executable on your shell PATH, or if CodeQL is not on your PATH, download and manage its own CodeQL executable (note: if you later introduce CodeQL on your PATH, the extension will prefer a CodeQL executable it has downloaded itself)."
},
"codeQL.cli.downloadTimeout":{
"type":"integer",
"default":10,
"description":"Download timeout in seconds for downloading the CLI distribution."
}
}
},
@@ -388,13 +378,28 @@
},
{
"type":"object",
"title":"Downloading databases",
"title":"Adding databases",
"order":6,
"properties":{
"codeQL.databaseDownload.allowHttp":{
"codeQL.addingDatabases.downloadTimeout":{
"type":"integer",
"default":10,
"description":"Download timeout in seconds for adding a CodeQL database."
},
"codeQL.addingDatabases.allowHttp":{
"type":"boolean",
"default":false,
"description":"Allow database to be downloaded via HTTP. Warning: enabling this option will allow downloading from insecure servers."
"description":"Allow databases to be downloaded via HTTP. Warning: enabling this option will allow downloading from insecure servers."
},
"codeQL.databaseDownload.allowHttp":{
"type":"boolean",
"markdownDeprecationMessage":"**Deprecated**: Please use `#codeQL.addingDatabases.allowHttp#` instead.",
"deprecationMessage":"Deprecated: Please use codeQL.addingDatabases.allowHttp instead."
"markdownDescription":"When adding a CodeQL database, automatically add the database's source folder as a workspace folder. Warning: enabling this option in a single-folder workspace will cause the workspace to reload as a [multi-root workspace](https://code.visualstudio.com/docs/editor/multi-root-workspaces). This may cause query history and database lists to be reset."
}
}
},
@@ -425,8 +430,41 @@
},
{
"type":"object",
"title":"Log insights",
"title":"GitHub Databases",
"order":8,
"properties":{
"codeQL.githubDatabase.download":{
"type":"string",
"default":"ask",
"enum":[
"ask",
"never"
],
"enumDescriptions":[
"Ask to download a GitHub database when a workspace is opened.",
"Never download a GitHub databases when a workspace is opened."
],
"description":"Ask to download a GitHub database when a workspace is opened."
},
"codeQL.githubDatabase.update":{
"type":"string",
"default":"ask",
"enum":[
"ask",
"never"
],
"enumDescriptions":[
"Ask to download an updated GitHub database when a new version is available.",
"Never download an updated GitHub database when a new version is available."
],
"description":"Ask to download an updated GitHub database when a new version is available."
}
}
},
{
"type":"object",
"title":"Log insights",
"order":9,
"properties":{
"codeQL.logInsights.joinOrderWarningThreshold":{
"type":"number",
@@ -440,19 +478,26 @@
{
"type":"object",
"title":"Telemetry",
"order":9,
"order":10,
"properties":{
"codeQL.telemetry.enableTelemetry":{
"type":"boolean",
"default":false,
"scope":"application",
"markdownDescription":"Specifies whether to send CodeQL usage telemetry. This setting AND the global `#telemetry.enableTelemetry#` setting must be checked for telemetry to be sent to GitHub. For more information, see the [telemetry documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code)"
"markdownDescription":"Specifies whether to send CodeQL usage telemetry. This setting AND the one of the global telemetry settings (`#telemetry.enableTelemetry#` or `#telemetry.telemetryLevel#`) must be enabled for telemetry to be sent to GitHub. For more information, see the [telemetry documentation](https://codeql.github.com/docs/codeql-for-visual-studio-code/about-telemetry-in-codeql-for-visual-studio-code)",
"tags":[
"telemetry",
"usesOnlineServices"
]
},
"codeQL.telemetry.logTelemetry":{
"type":"boolean",
"default":false,
"scope":"application",
"description":"Specifies whether or not to write telemetry events to the extension log."
"description":"Specifies whether or not to write telemetry events to the extension log.",
* See https://docs.github.com/en/rest/releases/releases#get-a-release for example response and response schema.
*
* This type must match the format of the GitHub API and is not intended to be used outside of this file except for tests. Please use the `Release` type instead.
*/
exportinterfaceGithubRelease{
assets: GithubReleaseAsset[];
created_at: string;
id: number;
name: string;
prerelease: boolean;
tag_name: string;
}
/**
* The json returned by github for an asset in a release.
* See https://docs.github.com/en/rest/releases/releases#get-a-release for example response and response schema.
*
* This type must match the format of the GitHub API and is not intended to be used outside of this file except for tests. Please use the `ReleaseAsset` type instead.
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.
