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.
@@ -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.
@@ -7,24 +7,20 @@ We should make sure the CodeQL for VS Code extension works with the Node.js vers
## Checking the version of Node.js supplied by VS Code
You can find this info by seleting "About Visual Studio Code" from the top menu.
You can find this info by selecting "About Visual Studio Code" from the top menu.

## Updating the Node.js version
The following files will need to be updated:
To update the Node.js version, run:
-`extensions/ql-vscode/.nvmrc` - this will enable nvm to automatically switch to the correct Node
version when you're in the project folder. It will also change the Nodeversion the GitHub Actions
workflows use.
-`extensions/ql-vscode/package.json` - the "engines.node: '[VERSION]'" setting
-`extensions/ql-vscode/package.json` - the "@types/node: '[VERSION]'" dependency
Then run `npm install` to update the `extensions/ql-vscode/package-lock.json` file.
```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. Our integration tests are currently pinned to an older version of VS Code. See [VS Code version used in tests](./vscode-version.md#vs-code-version-used-in-tests) for more information.
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. 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.
- 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.
- 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.
- 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 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.
- 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. 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.
- 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. Create a new tag on the release branch with your new version (named after the release), e.g.
@@ -37,8 +37,8 @@
```
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.
- 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:
```bash
@@ -46,13 +46,13 @@
```
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.
- 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. 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.
- 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.
* 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 run 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_ 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
- 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
@@ -24,10 +24,18 @@ Also consider what percentage of our users are using each VS Code version. This
## 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 stagging this update across two releases it gives users on older VS Code versions a chance to upgrade before it silently refuses to upgrade them.
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
Our integration tests are currently pinned to use an older version of VS Code due to <https://github.com/github/vscode-codeql/issues/2402>.
This version is specified in [`jest-runner-vscode.config.base.js`](https://github.com/github/vscode-codeql/blob/d93f2b67c84e79737b0ce4bb74e31558b5f5166e/extensions/ql-vscode/test/vscode-tests/jest-runner-vscode.config.base.js#L17).
Until this is resolved this will limit us updating our minimum supported version of VS Code.
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.
@@ -47,7 +88,7 @@ No user facing changes.
## 1.9.0 - 19 September 2023
- Release the [CodeQL model editor](https://codeql.github.com/docs/codeql/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)
- 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)
@@ -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).
"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."
}
}
},
@@ -375,6 +381,11 @@
"title":"Adding databases",
"order":6,
"properties":{
"codeQL.addingDatabases.downloadTimeout":{
"type":"integer",
"default":10,
"description":"Download timeout in seconds for adding a CodeQL database."
},
"codeQL.addingDatabases.allowHttp":{
"type":"boolean",
"default":false,
@@ -419,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."
* 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.