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.
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.
2023-10-25 14:22:55 +02:00
770 changed files with 35951 additions and 50509 deletions
@@ -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.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. See the [Node.js version instructions](./node-version.md) for more information.
- 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
@@ -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.
- 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)
@@ -30,7 +82,7 @@
## 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":"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."
}
}
},
@@ -409,8 +420,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.