pick 2db42e3e Pull out createDataExtensionYamls into yaml.ts
pick 52f7cac0 Move saveModeledMethods to a separate file
pick ba27230e Move loadModeledMethods to a separate file
pick c512a11e Split out listModelFiles from loadModeledMethods
pick 752cf8ab Add some tests of listModelFiles
This removes the call type as shown for an unmodelable method. We still
need to decide how to show this information, so this may be added back
in later.
* Move code-tour.ts to /code-tour
* Move qlpack-generator.ts to /local-queries
* Move query-status.ts to /query-history
* Move skeleton-query-wizard.ts to /local-queries
* Add version constraint for Check errors
* Refactor parts of the ideserver out of extension.ts
* Give visibility information to the ide-server.
This allows it to report errors on visible files
eagerly.
This adds a refresh button to the data extensions editor when the
framework mode feature flag is enabled. If you are using framework mode,
you can have multiple tabs of the data extensions editor open in which
you are modeling the library separately from the application. When you
save the library in framework mode, the application mode will not
refresh and show that these calls have been modeled. Rather than using
apply, which might also save all modeled methods, you can now use the
refresh button to refresh the external API usages and whether they are
supported.
This excludes methods defined in tests in framework mode, significantly
cutting down on the number of methods shown that would need to be
modeled.
For C#, this just checks that the file is not a test file, as defined
by the QL library.
For Java, this makes a copy of the internal
[`ModelExclusions.qll`](249f9f863d/java/ql/lib/semmle/code/java/dataflow/internal/ModelExclusions.qll)
file to avoid the use of internal modules. This module will tell us
whether a method is "interesting" to model or not. Not all of the checks
in this module need to happen for framework mode, but these checks might
be useful for telling a user whether a method is interesting to model
in application mode.
This makes the method name and parameters in framework mode a link to
the definition of the method. In framework mode, the `usages` contains
1 element, which is the location of the definition of the method.
Therefore, we can simply use `jumpToUsage` to jump to the definition.
Similar to https://github.com/github/vscode-codeql/pull/2553, this
changes the C# query to correctly report the name of nested types. I
couldn't find a `nestedName` method for C#, so this adds one in the
`AutomodelVsCode` library.
C# seems to use `+` as a separator for nested types, as reported by
`getQualifiedName()`:
```
GitHub.Nested.MyFirstClass+NestedClass
```
The `getApiName()` will now report:
```
GitHub.Nested#MyFirstClass+NestedClass.Test()
```
Adds a command to run all queries in a certain folder.
This uses the existing `runQueries` command, which lets you run multiple queries against the selected local database.
We don't have a corresponding command for running multiple variant analysis queries, so I haven't implemented that.
This changes the Java `CallableMethod.getApiName()` to use `nestedName`
instead of `getSourceDeclaration`. `getSourceDeclaration` would return a
`RefType`, on which the `toString()` method returns its `getName`().
However, for nested types this wouldn't work and wouldn't include the
enclosing type. This fixes it by using `nestedName` which matches the
method that is also used for determining whether a type matches an
extensible predicate.
* Add version constraint for quick-eval-count
* Add quick eval count context.
* Add support for running quick-eval-count from the command pallete
* Adjust name for quick-eval-count-queries
* Add changenote for quick-eval-count.
* QuickEval:Address review comments
* Fix rebase conflict in changelog
This refactors the data extensions editor queries to use a new
`AutomodelVsCode` module. This module is based on the `ExternalApi`
module, but is more general and can be used for retrieving public
methods from the source as well. The actual conditions are now in the
queries themselves.
This reduces the duplicated module in the framework mode query and will
mean that when we update the `ExternalApi` module, we will just have to
port it to the `AutomodelVsCode` module, and not to the `ExternalApi`
and a separate framework mode query.
This changes the sorting of the methods sent to LLM to match the order
shown in the data extensions editor. This will ensure that the methods
which are shown first in the data extensions editor are also modeled
first.
This will allow users to override the default directory in which
extension packs are created by using the
`codeQL.dataExtensions.extensionsDirectory` setting. This setting can be
overriden per language, so the user could create the following
configuration to set the extension pack setting for Java only:
```json
"[java]": {
"codeQL.dataExtensions.extensionsDirectory": "/Users/user/github/vscode-codeql-starter/codeql-custom-queries-java",
}
```
This will remove the user input for a model file and will instead create
1 model file per library (JAR/DLL). The model filename will be based on
the JAR/DLL name, but will remove the version number and the file
extension. It will also normalize the name.
These files will be created automatically, and the editor now also reads
in all files contained in an extension pack to read the modeled methods.
This could result in duplicates if the user has created a different file
to contain the same modeled methods, but this is an edge-case that we're
explicitly not handling.
The `logging` part of `common` was exported in `common/index.ts` and
could be imported by importing `common`. I don't think this makes a lot
of sense, so I removed it.
The `common/logging/index.ts` also contained exports of the
`common/logging/vscode` directory, which means that importing
`common/logging` automatically brings in the `vscode` module. This
removes that export, so now there are two separate imports needed for
importing the common part and the `vscode` specific part. This should
make it easier to keep them separate and be more explicit about what
you're importing.
This will change how extension packs are named in the data extensions
editor. Before, the user had to pick a workspace folder and a name for
the extension pack. Now, the workspace folder will be picked
automatically if we can detect it (i.e. it follows the naming structure
we expect), or the user will still need to select it. The extension pack
name is always auto-generated based on the database name and the
database language.
This adds a new `codeQL.dataExtensions.disableAutoNameExtensionPack`
setting to disable this behavior while we are still working on changing
how the data extensions editor works.
This adds a new library column to the data extensions editor containing
the JAR or DLL file the method is defined in. This will be used to group
methods by library in the future. For now, it just shows in a column.
See https://github.com/github/vscode-codeql/pull/2490#discussion_r1226437598
for more explanation. This will make the class more useful for future usecases
where we don't want the behaviour of only calling update when there isn't
another refresh scheduled. I also think it doesn't negatively affect other
users such as the query test discovery. The effect should be that we'll see
more updates to the UI. These updates will get overwritten quickly, but they
are all genuine snapshots of the filesystem at the point the discovery process
ran, so they aren't incorrect, or aren't more incorrect than continuing to show
the old state before any discovery ran.
To increase the use of the `app` logger, this replaces the direct use of
`extLogger` by the `app.logger` where possible. This should not change
the behavior since the `extLogger` is the logger used by the `app`.
This moves the `showAndLog` family of functions to the `common/logging`
directory. It explicitly moves the `showAndLogExceptionWithTelemetry`
function to the `common/vscode/logging.ts` file because it still has a
dependency on the `telemetryListener`, which depends on the `vscode`
module.
It seems like some CLI tests are hanging and only completing after 6
hours when they run into the default timeout. This updates the timeout
to 30 minutes. All CLI tests should complete in 30 minutes, so this
should ensure that they are cancelled when they are stuck.
This moves the Webview HTML generation used by `AbstractWebview` out of
`interface-utils.ts` and into a new file `webview-html.ts` in the
`common/vscode` directory.
When packaging an extension pack, unscoped extension pack names are not
allowed and calling `codeql pack bundle` will fail with an error. This
command will be called when running a variant analysis, so these packs
will not work for a variant analysis.
To improve the user experience, we now only allow scoped extension pack
names. This means that the user will now have to enter a scope when
creating a new extension pack.
This option was used to ignore source archives for `.testproj`
databases. It is only set to `true` or `false` when creating the
database and could not be changed, so I don't think we need this option.
It can simply be derived from the database URI. This simplifies handling
of databases a bit.
This moves the `refresh` method from `DatabaseItem` to `DatabaseManager`
and makes it private. This makes the `DatabaseItem` interface smaller
and more focused and ensures that `refresh` cannot be called from
outside of the `DatabaseManager`.
This will allow us to implement specific behavior on the
`DatabaseItemImpl` which is not available on the `DatabaseItem`. This
will allow us to make the surface area of the `DatabaseItem` smaller.
Generated variant analysis packs will use the original name
of the pack that the query is located in. This is to support
some future work where we do extra validation of data extensions.
If the query is not in a pack, the default name is used.
This adds a warning when the user is using an unsupported version of the
CodeQL CLI. The warning is shown once per session, and only if the
version is older than the oldest supported version.
When the user filters the repositories, the buttons should reflect that
the results are filtered and that the user is not exporting or copying
all the results. If the user has selected repositories, the buttons
should still say that they are exporting selected results.
This changes the text of the export/copy buttons on a variant analysis
when at least one repository is selected. This makes it more clear that
the user is only exporting/copying the results of the selected
repositories.
The compare view typically works by matching the results sets of
queries. It only allows the results sets of queries with identical
names to be compared.
Manually run queries use `#select` as the default result set. However,
quick eval queries use a different, generated, name. Therefore, these
two kinds of queries cannot be compared.
This commit changes the heuristics so that if there are no identical;y
named results sets, the first result set of each query that is prefixed
with `#` is used (this is the default result set).
It also makes a slightly nicer error message if there are no comparable
results sets.
The data extensions editor was always setting the `provenance` field of
MaD to `manual`. This will change the `provenance` to be either
`editor-manual` (for models which were added by the user),
`df-generated` (for models generated by the dataflow generator), and
`df-manual` (for models generated and then edited). This makes it easier
to trace the origin of a model.
This will change the data extensions editor generator to resolve the
queries based on the `modelgenerator` tag. This removes the requirement
of having a `ql` folder in the workspace.
I chose to use the path instead of the `id` for now to avoid having to
resolve the query 4 times. This also avoids the need to map the language
names to the language ID in the tag (i.e. `csharp` -> `cs`).
* Log stdout when servers are terminated with errors.
This logs the last stdout chunk (probabaly the last line) if things
went wrong. This can sometimes be useful for debugging.
It also prints the signal when killed by a signal
(rather than printing null)
* Restart/Abort the queryserver if the process dies.
This cancels any running tasks and gives a limited number of restarts.
* Update extensions/ql-vscode/src/codeql-cli/cli.ts
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
* Update extensions/ql-vscode/src/query-server/query-server-client.ts
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
---------
Co-authored-by: Andrew Eisenberg <aeisenberg@github.com>
`url.parse` is deprecated and should be replaced by the WHATWG URL API,
so this makes that change. The `protocol` and `host` properties are
unchanged, so no other changes are needed.
This will make both the `askForLanguage` and `findLanguage` functions
return a `QueryLanguage` instead of a `string`. This will make it harder
to make mistakes when using these functions.
There are also some other changes with regards to `QueryLanguage` such
that we never need to use `as QueryLanguage` explicitly anymore, except
for the new `isQueryLanguage` function. The only remaining place that I
know of where we're using a `string` to represent the `QueryLanguage`
is in a database item's language, but this is harder to change and may
be relied upon by language authors.
This will suppress showing the same error message when monitoring the
variant analysis fails multiple times in a row. This is useful when
e.g. the internet is disconnected or the endpoint is non-functional for
any other reason.
This will show the error message at least once, and then only show it
if there has been a successful attempt in between or when the error
message is different. This should result in a much less noisy
experience.
For `@kind problem` queries, it seems like the BQRS contains four
result sets: `edges`, `nodes`, `subpaths`, and `#select`. The user is
probably interested in the results of `#select` since that contains the
direct result of the query. This changes the extraction of raw (BQRS)
results to always prefer `#select` over any other result set. If it
can't find a result set named `#select`, it will fall back to the first
result set in the BQRS like before.
After some bit of refactoring, the templates are no longer being
passed to the CFG viewer and this is preventing the viewer from
running.
This change fixes it.
An internal option to help library authours to run and debug
the find references and find dependencies contetextual queries
without relying on the implicit cache.
I initially started defining an enum, but I'm not able to import it in package.json,
where the list of options is defined (under `codeQL.createQuery.autogenerateQlPacks`).
This was only a problem for the new test UI, because the third-party Test Explorer extension we used before must have had this filter in its implementation.
When running "Create Query", if the user escapes out of the language quickpick we don't need to throw an error. Instead we can just show a `UserCancellationException` notice.
We were only clearing the pack cache when a pack file was modified. When
using a script to create a new pack, the pack file is created at once
without a change event firing. This will change the behavior to also
clear the pack cache when a pack file is created or deleted.
And add tests to check this.
I've had to adapt the existing `findExistingDatabaseItem` method
so receive params so that I'm better able to send it a language
and a list of database items.
Offer non-codespace users the option to configure their storage folder for skeleton packs.
Suggested here:
https://github.com/github/vscode-codeql/pull/2310#issuecomment-1507428217
At the moment we're choosing to create our skeleton packs in the first
folder in the workspace.
This is fine for the codespace template because we can control the
folder structure in that repo.
For users outside of this we'd like to offer them the option to choose
where to save their skeleton packs.
After some testing of the wizard with a single rooted workspace
(`github/code-scanning`) we discovered a general VSCode extension
bug whereby after we download a database, we don't select it.
This isn't an issue in the wizard, but it does affect us as it means
we'll generate the QL pack, download the db for you but then you won't
know that we haven't selected your database.
So let's make sure our flow works for this case by explicitly selecting
the database once it's downloaded.
We've noticed by testing that we need to set the current database item
before we call `addDatabaseSourceArchiveFolder()`. Once that method is
called, the call to `setCurrentDatabaseItem()` is ignored.
We've had to make some changes to the openDatabase() method to select
a database item by default, since most places where we call `openDatabase()`
also immediately select the item.
There is one exception [1] in the test-runner.ts file, where we set the
current database item under special conditions.
For this reason, we've made the behaviour configurable and tried to add
some descriptive naming to the params so that it's easy to understand
what the config is doing.
[1]: 4170e7f7a7/extensions/ql-vscode/src/test-runner.ts (L120-L124)
This removes the link to the model file when it does not exist. It will
still show the filename of the model file. When clicking on "Apply", it
will refresh whether the model file exists after writing the file.
This fixes an issue where we would download a database every time
we create a new QL pack. Sometimes, a database is already available
so let's always check for it, regardless of the existence of a QL
pack.
This will filter the extension packs shown to the user when selecting an
extension pack to use in the data extension editor to only include the
extension packs that are compatible with the language of the database
item.
Unfortunately, this required quite some changes to the tests to ensure
the extension packs are actually setup properly since it's now reading
the extension pack files.
This will add the extension pack name to the data extensions editor and
allow the user to click on it to go to the folder of the extension pack
in the explorer panel.
This adds the model filename to the data extensions editor and will also
allow the user to go to the model file by clicking on the filename.
This also updates the general UI to be somewhat more compact by moving
the modeled percentages to be below the header in 1 line.
When you have just created a model file using the quick picker/input
box, the data extension editor will try to read it and fail with an
error message. This adds a check to ensure the model file exists and if
it doesn't, it will not try to read in the file.
This should always be safe since the model file picker will only allow
you to select existing files.
This will not allow the user to open the data extensions editor for a
database if it is not one of the supported languages. The supported
languages is a list of `string` rather than a list of `QueryLanguage`
because a database item's language is also a `string`.
There were still some places where we were hardcoding Java in the data
extension editor. This changes these places to use the database item
language instead.
This commit addresses various test flakiness:
1. Bump timeouts for queries tests
2. Add a dispose handler to queryserver-client. This will help us during
tests because if there is a test that timesout while a query is
running, the query's progress callback won't be invoked. We will
still get a timeout error in the first test, but the second test will
not get a spurious error.
3. Handle a disposed query server in `deregisterDatabase`. This method
will remove the database from the currently running query server.
If there is no query server, then there is nothing to remove. So,
this error is safe to ignore.
4. Explicitly `end()` a connection `ServerProcess`. I'm not 100% sure if
this is necessary, but it seems like it prevents responses from being
handled and erroring out.
5. Better handling of ideServer restarts. Previously, if you quickly
called `CodeQL: Restart Query Server` twice in a row, you would get
an error from the ideServer restart. Restart fails if the server is
not already started. So, in this case just call a start.
We've made an exception to fetch the parent folder when we're
in the vscode-codeql-starter workspace.
We'd like to make this more specific so that it doesn't interfere
with other repos.
When running Create Query in the codespaces-codeql repo, it successfully
creates codeql-custom-queries-xxx as a subfolder of the first workspace
folder, and then adds a database. After the database gets added, we get
prompted with this message:
```
We've noticed you don't have a CodeQL pack available to analyze this
database. Can we set up a query pack for you?
```
which would try to create another QL pack.
Since we're no longer pushing QL packs as top level folders in the
workspace when we use the new "Create Query" flow, we also need to adapt
the original flow to take into account subfolders.
Just as a reminder, the original flow is:
- Be in the codespace template
- Download a database from GitHub
- The extension will offer to create a QL pack for the database
The new flow:
- Run the "Create Query" command
- Choose a language
- Create a QL pack
- Download a database for it
In the new flow the last step of downloading a database would trigger
the extension to offer to create a QL pack.
Let's fix this by detecting subfolders as well and exiting early.
This sets a default timeout of 3 minutes on CLI integration tests. This
is because these tests call into the CLI and execute queries, so these
are expected to take a lot longer than the default 5 seconds. This
allows us to remove all the individual `jest.setTimeout` calls with
different values from the test files.
Set the CLI version in the telemetry listener whenever the version
changes.
A few things to note here:
1. In `CliServer::getVersion()`, avoid calling `supportsPerQueryEvalLog`
directly. This avoids a recursive call to `CliServer::getVersion()`.
Currently, it's always safe to do this, but I thought that it would
be good to avoid recursion here in case we change things in the
future.
2. Now, we are sending the CLI version with all telemetry events.
This adds the external API query text to the extension directly to avoid
users having to copy the query to their local `codeql` submodule or
having to checkout a specific branch.
This is a temporary solution until the queries are stabilized. Once they
are, we will upstream these to `github/codeql` and use them like other
contextual queries.
Since this is just a temporary solution, this is not the prettiest code
and is not intended to be a long-term solution. It does not do proper
caching and will create a new temporary directory for every query run.
The performance hit of this is acceptable and expected.
When we create a skeleton query, we check whether you already have an
existing database with the same name (e.g. `github/codeql`). If we can't
find one, we also check for an existing database with the same language.
If we find one, we select it instead of downloading a new database.
Here we're filtering out databases with errors.
In the original flow for creating skeleton packs, we were starting out
by choosing a database (e.g. github/codeql) and having the extension
create the QL pack for us.
At that point, we were storing the QL pack together with the database in
the extension storage because we weren't interested in committing it to
the repo.
This means we weren't able to see it in the file explorer so in order to
make it visible, we decided to push it as a top-level folder in the
workspace.
Hindsight is 20/20.
Let's change this original flow by just creating the folder in the
workspace storage instead of the extension storage (which will make it
visible in the file explorer) and stop pushing it as an extra top level
folder in the workspace.
NB: For this flow, we exit early in the `createSkeletonPacks` method if
the folder already exists so we don't need to check this again.
This adds the CLI version to telemetry command-usage events.
Note that the CLI server is created after the telemetry listener is
created. The first few telemetry events may have a "not-set" value for
the CLI version.
This changes the kind input from a text field to a dropdown in the data
extensions editor. The supported values for each extensible predicate
are based on what is currently in-scope for the documentation. Other
kinds are not supported.
The supported kinds are now stored on the
`extensiblePredicateDefinitions` to make it easier to add new kinds in
the future.
We now use `fsPath` instead of `path`.
Note: I haven't yet fixed the tests, nor checked manually on mac/linux
Tangential change: we now use the `dirname` method, instead of manually splitting paths to get a parent folder.
The `getFirstStoragePath()` method would break on windows:
```
Path contains invalid characters: /c:/git-repo/codespaces-codeql (codeQL.createSkeletonQuery)
```
This makes sense, since we're looking to get the parent folder by splitting for `/`.
In windows, paths use `\` instead of `/`.
So let's detect the platform and add a test for this case.
To be consistent with other database item search methods, we're renaming
ours:
`digForDatabaseItem` -> `findDatabaseItemByNwo`
and
`digForDatabaseItemSameLanguage` -> `findDatabaseItemByLanguage`
At the moment, we're always deciding which database to download for the
user for an example query.
We'd like to give them a chance to change the database, so here we're
adding a step where we're showing the user a selection box with the
suggested database pre-filled.
They can choose to type in a different database before continuing the
skeleton generation process.
We'd like to select an existing database for our query, if on is
already downloaded and matches the query language.
Previously we were re-using the database if the language and name
matched (e.g. the name would be `github/codeql`).
When we try to determine the next file name for our example query,
we only look at `example<n>.ql` files.
e.g. if the files in the folder are:
- `example.ql`
- `example2.ql`
- `MyQuery.ql`
we will create an `example3.ql` file.
Previously we were counting all existing `.ql` files.
We've now added more tests and pushed the total duration over 5 seconds
for all the tests in this file.
This limitation seems to be a recent development where files with tests
that last longer than 5 seconds start failing in jest.
We're bumping the timeout limit to 40 seconds for now.
We initially defined the default database to download as one from the
`github/codeql` repo as it was convenient.
However, this repo doesn't have a lot of vulnerabilities to discover.
Let's use repos that are in our MRVA top 10 list to allow users to
write more interesting queries.
We set up the "Create Query" command with the assumption that
the first folder in the workspace is the parent folder.
This is true for the `codespaces-codeql` repo where we expect
to use this command.
However, for the `vscode-codeql-starter` repo, the top level
folders are QL packs:
- codeql-custom-queries-cpp
- codeql-custom-queries-ruby
... etc.
In order to make the command work for people using the starter
repo, we'll need to introduce a check for these QL packs when
we decide the storage path.
The end goal is to replace the starter workspace completely
with the codespaces-codeql repo, so this code can be removed
in the future when we retire the repo.
Until then, the command will need this to be able to work in
both starter workspaces.
We offer `github/codeql` as a repo to use for downloading databases
for our skeleton pack.
Once the repo is specified, the user is prompted to choose a language.
At this point, we already know what language the user wants, so let's
change the `downloadGitHubDatabase` and `convertGithubNwoToDatabaseUrl`
methods to accept a language parameter.
We check if the language is in the list of languages received in the
response. If it isn't, we still prompt the user.
This will be triggered by a "Create Query" command.
It will:
- prompt the user for a language
- create a skeleton pack based on the language chosen
- download a database for the QL pack
- open the new query file
If the skeleton pack already exists, we just create a new query file
in the existing folder.
If the database is already downloaded, we just re-use it.
We introduced this QlPackGenerator a while ago. It always creates an `example.ql` query file as part of the skeleton pack.
We'd like to set the name of the query file, since we'll allow the user to create queries multiple times in the same skeleton pack folder.
The folder will be named `codeql-custom-queries-${language}` and will first receive an `example.ql` file.
If the user then tries to create a new query for the same language, we'll just create an `example2.ql`, `example3.ql` etc. file in the existing folder.
We'll use this to check whether a database for our ql pack already exists.
While there are other methods that search for a database item by URI, we
only have a language chosen by the user and an nwo ("github/codeql").
So let's introduce a way to search for the db based on the information we
have.
We plan to ask the user to choose a language, before attempting
to download a corresponding database for them.
The functionality already exists, so let's re-use it.
This was nested in a method that included prompting the user for a
github repo.
We'd like to re-use this to download a database of our choice from
GitHub, based on which language a user chooses.
This will allow a user to create a new model file in an existing data
extension when opening the data extension editor. There is some
validation on the name of the model file, which depends on reading in
the qlpack.
This adds a pickable model filename from an existing extension pack to
the data extensions editor. This allows the user to edit one of their
existing data extensions. This does not yet add the ability to create
new extension packs and/or new model files.
This uses the `codeql resolve extensions` command to get the list of
available model files. This should be available in all CLI versions
which the data extensions editor supports.
The data extension editor was only using the default data extensions
found in the `ql` submodule to find external API calls. This will add
support for using data extensions found in the workspace.
Rather than using the `codeQL.runningQueries.useExtensionPacks` setting,
this will always include data extensions since the editor doesn't make
sense to use without data extensions. We will also forbid the user from
opening this view unless they are using a CLI which supports data
extension packs.
We were using a single-use class for generating the flow model, while we
are actually able to do it using two functions. This is more in line
with our existing codebase.
This fixes the "Webview is disposed" error which occurs when the user
closes the variant analysis webview while the extension is still
activating. We will now check whether the webview is disposed before
restoring the view.
This was pointed out by CodeQL: when calling `setState` and using
`this.props`, it may not be up-to-date because `setState` may run
concurrently. Therefore, we should use the `setState` callback variant
to ensure we get the latest props.
This refactors the code a bit to ensure we're not using `this.props`
anywhere, including in the `getResultSets` function which is called
in the `setState` callback.
When updating to React 18, we removed the loading step from the updating
of the state of the result view since React would batch the updates
anyway. However, this caused a bug where the result view would be empty
when switching between queries. This is because the result view would
retain the old selected result set name. This would not happen
previously because React would re-render the view at least once, which
would cause the result view to be unmounted and re-created.
This fixes it by resetting the selected result set if we can't find the
result set in the new result sets.
The default Storybook Babel config did not recognize the `public`
keyword in our custom errors (e.g. `ExhaustivityCheckingError`
and `RedactableError`). To fix this, we can use Storybook's V7 mode to
supply a custom Babel config. This fixes the compilation error.
See: https://storybook.js.org/docs/react/configure/babel
This adds tests for the external API query and retrieving of results. It
does not use the "real" CLI integration, but instead mocks the CLI
server and query runner.
To make mocking easier and require less type casting, I've narrowed some
of the arguments of some other functions. They now use `Pick` to only
require the properties they need.
The version of ts-jest we were using was given a warning that it did
not support TypeScript 5, even though it was working fine. The latest
version of ts-jest adds official support for TypeScript and removes the
warning.
This loads in the existing data extension YAML file for the selected
database. It only supports the filename we save it to, and will not load
it from any other data extension YAML files.
This adds the ability to save the modeled methods in the data extensions
editor to a YAML file named after the database name. It will save it to
the `ql` submodule for now. Support for data extension packs will be
added later.
This updates the view of the data extensions editor to show a table of
possible sources/sinks/flow summaries that can be edited. It's not yet
possible to save the changes or load the existing file.
This upgrades Storybook to an alpha version to ensure we can start
Storybook when using TypeScript 5.0. This is temporary until we can
upgrade to Storybook 7 or to a released version of 6.5.17.
This adds a really simple regression unit test for the results view
which checks that the results view can render a SARIF file. This is
in preparation for the upgrade to React 18 to ensure that we don't
break the basic functionality of the results view.
This will improve the error message shown when monitoring fails. Instead
of showing "Error while monitoring variant analysis: Not Found", this
will now show "Error while monitoring variant analysis "Empty block
(javascript) [29/3/2023 10:45:10]: Not Found". This should make it
easier for the user to figure out which query history item is
problematic.
We're not using the full query history item label here because that
would require access to the query history item, which we don't yet have
here. Adding it here would add a dependency on the query history, which
seems undesirable.
We were ignoring errors coming from `vsce publish` and this was causing
the workflow to succeed even when the publish failed. This will remove
the `||` and let the workflow fail if the publish fails.
The `glob` package now uses promises in version 9, so we don't need the
separate `glob-promise` package anymore.
This also updates one call site to use `cwd` instead of `join` to
avoid possible issues due to a breaking change in version 8 which treats
Windows path separators differently. By changing the `cwd`, we should
not run into these issues.
Removing the `resolutions` of `glob-parent` did not change the
`package-lock.json`, so this does not have any effect on the package
version we are using.
We introduced this change to help with reducing flakiness in CI [1].
This has a slightly different effect locally, where every failed test
will output three times.
This in turn makes it harder to read, especially when you have multiple
failing tests.
Since the original intent for this behaviour was to be used in CI, I'm
proposing we disable it when the CI env variable isn't set.
I've opted to set it for all jobs involving tests, just for consistency.
I'm happy to limit it to just the places where it's required.
[1]: https://github.com/github/vscode-codeql/pull/2059
This adds support for detecting the `CommandManager.execute` method in
the unique command use query.
This may not be the best way to implement this. There's a method
`hasUnderlyingType` on `this.getReceiver().getType()`, but I couldn't
really figure out how to get it recognize `CommandManager`. It might be
possible if we can construct the type of `CommandManager`, but this will
probably include the filepath to the `CommandManager` class, which might
not neccessarily be something we want: moving the `CommandManager` class
should not require updating the query. I'm very happy to hear other
suggestions.
The `commandRunner` name doesn't really make sense since it doesn't
"run" a command, but rather registers a command. This renames it
to `registerCommandWithErrorHandling` and moves it to the
`common/vscode` directory.
In the results view, `setState` was used to set some state, and then
`loadResults` was called to set some other state. However, `setState`
is asynchronous, so the `this.state` in `loadResults` was not the state
that was set before the call.
This commit fixes it by combining the two `setState` calls into one. The
logic was hard to follow, so I'm not sure if this is the correct fix.
The `shouldKeepOldResultsWhileRendering` state seems to be unnecessary
now since everything is being done in `setState` call, but I'm not sure
about that.
The version of `@primer/react` we were using didn't have the correct
types for the `ThemeProvider`. By upgrading these packages to their
latest versions, all types are correct.
This enables React strict mode which will print extra warnings to the
console when we use certain constructs incorrectly. This does not affect
production builds.
See https://beta.reactjs.org/reference/react/StrictMode
@@ -67,10 +67,7 @@ members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
[homepage]: https://www.contributor-covenant.org
This Code of Conduct is adapted from the [Contributor Covenant, version 1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html).
For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq
[the Contributor Covenant FAQ](https://www.contributor-covenant.org/faq). For more about Contributor Covenant, see [the Contributor Covenant website](https://www.contributor-covenant.org).
@@ -23,7 +23,9 @@ 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).
* 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).
@@ -93,7 +95,7 @@ More information about Storybook can be found inside the **Overview** page once
### Testing
Information about testing can be found [here](./docs/testing.md).
[Information about testing can be found here](./docs/testing.md).
@@ -25,8 +25,8 @@ This project will track new feature development in CodeQL and, whenever appropri
This extension depends on the following two extensions for required functionality. They will be installed automatically when you install VS Code CodeQL.
* 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. If it doesn't, you will then need to update the node version in the following files:
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
*`.github/workflows/main.yml` - all the "node-version: '[VERSION]'" settings
*`.github/workflows/release.yml` - the "node-version: '[VERSION]'" setting
1. Double-check that the extension `package.json` and `package-lock.json` have the version you intend to release. If you are doing a patch release (as opposed to minor or major version) this should already be correct.
1. Create a PR for this release:
* This PR will contain any missing bits from steps 1, 2 and 3. Most of the time, this will just be updating `CHANGELOG.md` with today's date.
@@ -22,7 +22,7 @@
* 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.
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"
@@ -30,15 +30,18 @@
1. Build the extension `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.
```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
```
```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"
@@ -68,7 +71,7 @@
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.
* 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>.
@@ -11,16 +11,67 @@ We don't need to test features (and permutations of features) that are covered b
## Before releasing the VS Code extension
-Go through the required test cases listed below
-Run at least one local query and MRVA using the existing version of the extension (to generate "old" query history items).
- Go through the required test cases listed below.
- Check major PRs since the previous release for specific one-off things to test. Based on that, you might want to
choose to go through some of the Optional Test Cases.
- Run a query using the existing version of the extension (to generate an "old" query history item)
## Required Test Cases
### Test Case 1: MRVA - Running a problem path query and viewing results
### Local databases
1. Open the [UnsafeJQueryPlugin query](https://github.com/github/codeql/blob/main/javascript/ql/src/Security/CWE-079/UnsafeJQueryPlugin.ql).
#### Test case 1: Download a database from GitHub
1. Click "Download Database from GitHub" and enter `angular-cn/ng-nice` and select the javascript language if prompted
#### Test case 2: Import a database from an archive
1. Obtain a javascript database for `babel/babel`
- You can do `gh api "/repos/babel/babel/code-scanning/codeql/databases/javascript" -H "Accept: application/zip" > babel.zip` to fetch a database from GitHub.
2. Click "Choose Database from Archive" and select the file you just downloaded above.
### Local queries
#### Test case 1: Running a path problem query and viewing results
1. Open the [javascript UnsafeJQueryPlugin query](https://github.com/github/codeql/blob/main/javascript/ql/src/Security/CWE-079/UnsafeJQueryPlugin.ql).
2. Select the `angular-cn/ng-nice` database (or download it if you don't have one already)
3. Run a local query.
4. Once the query completes:
- Check that the result messages are rendered
- Check that the paths can be opened and paths are rendered correctly
- Check that alert locations can be clicked on
#### Test case 2: Running a problem query and viewing results
1. Open the [javascript UnsafeJQueryPlugin query](https://github.com/github/codeql/blob/main/javascript/ql/src/Security/CWE-079/UnsafeJQueryPlugin.ql).
2. Select the `babel/babel` database (or download it if you don't have one already)
3. Run a local query.
4. Once the query completes:
- Check that the result messages are rendered
- Check that alert locations can be clicked on
#### Test case 3: Running a non-probem query and viewing results
1. Open the [cpp FunLinesOfCode query](https://github.com/github/codeql/blob/main/cpp/ql/src/Metrics/Functions/FunLinesOfCode.ql).
2. Select the `google/brotli` database (or download it if you don't have one already)
3. Run a local query.
4. Once the query completes:
- Check that the results table is rendered
- Check that alert locations can be clicked on
#### Test case 3: Can use AST viewer
1. Click on any code location from a previous query to open a source file from a database
2. Open the AST viewing panel and click "View AST"
3. Once the AST is computed:
- Check that it can be navigated
### MRVA
#### Test Case 1: Running a path problem query and viewing results
1. Open the [javascript UnsafeJQueryPlugin query](https://github.com/github/codeql/blob/main/javascript/ql/src/Security/CWE-079/UnsafeJQueryPlugin.ql).
2. Run a MRVA against the following repo list:
```json
@@ -47,49 +98,56 @@ choose to go through some of the Optional Test Cases.
6. Once the query completes:
- Check that the query history item is updated to show the query status as "complete"
### Test Case 2: MRVA - Running a problem query and viewing results
#### Test Case 2: Running a problem query and viewing results
1. Open the [ReDoS query](https://github.com/github/codeql/blob/main/javascript/ql/src/Performance/ReDoS.ql).
1. Open the [javascript ReDoS query](https://github.com/github/codeql/blob/main/javascript/ql/src/Performance/ReDoS.ql).
2. Run a MRVA against the "Top 10" repositories.
3. Check that there is a notification message.
3. Check that a notification message pops up and the results view is opened.
4. Check the query history. It should:
- Show that an item has been added to the query history
- The item should be marked as "in progress".
5. Once the query starts:
- Check that a notification is shown with a link to the results view
5. Once the query completes:
- Check that the results are rendered with an alert message and a highlighted code snippet:
1. Open the [FunLinesOfCode query](https://github.com/github/codeql/blob/main/cpp/ql/src/Metrics/Functions/FunLinesOfCode.ql).
#### Test Case 3: Running a non-problem query and viewing results
1. Open the [cpp FunLinesOfCode query](https://github.com/github/codeql/blob/main/cpp/ql/src/Metrics/Functions/FunLinesOfCode.ql).
2. Run a MRVA against a single repository (e.g. `google/brotli`).
3.Once the query starts:
- Open the query results
3.Check that a notification message pops up and the results view is opened.
4. Check the query history. It should:
- Show that an item has been added to the query history
- The item should be marked as "in progress".
5. Once the query completes:
- Check that the results show up in a table:
### Test Case 4: MRVA - Interacting with query history
#### Test Case 4: Interacting with query history
1. Click a history item (for MRVA):
- Check that exporting results works
- Check that sorting results works
- Check that copying repo lists works
2.Open the query results directory:
2.Click "Open Results Directory":
- Check that the correct directory is opened and there are results in it
3. View logs
3.Click "View Logs":
- Check that the correct workflow is opened
### Test Case 5: MRVA - Canceling a variant analysis run
#### Test Case 5: Canceling a variant analysis run
Run one of the above MRVAs, but cancel it from within VS Code:
- Check that the query is canceled and the query history item is updated.
- Check that the workflow run is also canceled.
- Check that any available results are visible in VS Code.
### Test Case 6: MRVA - Change to a different colour theme
### General
Open one of the above MRVAs, try changing to a different colour theme and check that everything looks sensible.
#### Test case 1: Change to a different colour theme
Open at least one of the above MRVAs and at least one local query, then try changing to a different colour theme and check that everything looks sensible.
Are there any components that are not showing up?
## Optional Test Cases
@@ -231,6 +289,7 @@ with this since it has quite a limited number of actions you can do.
This requires running a MRVA query and seeing the results view.
<!-- markdownlint-disable-next-line MD024 -->
#### Test case 1: When variant analysis state is "pending"
1. Can open a results view
@@ -256,10 +315,10 @@ This requires running a MRVA query and seeing the results view.
2. When the file does not exist
7. Can open query text
8. Can sort repos
1.By name
2. By results
3. By stars
4. By last updated
1.Alphabetically
2. By number of results
3. By popularity
4. By most recent commit
9. Can filter repos
10. Shows correct statistics
1. Total number of results
@@ -319,6 +378,7 @@ This requires running a MRVA query and seeing the results view.
1. Make changes via config file (ensure JSON schema is helping out)
1. Close and re-open VS Code (ensure lists are there)
1. Collapse/expand tree nodes
1. Create a new list, right click and select "Add repositories with GitHub Code Search". Enter the language 'python' and the query "UserMixin". This should show a rate limiting notification after a while but eventually populate the list with roughly 770 items.
@@ -18,6 +18,7 @@ Any test data you're using (sample projects, config files, etc.) must go in a `t
## Running the tests
Pre-requisites:
1. Run `npm run build`.
2. You will need to have `npm run watch` running in the background.
@@ -29,7 +30,7 @@ Then, from the `extensions/ql-vscode` directory, use the appropriate command to
* View Tests: `npm test:view`
* VSCode integration tests: `npm run test:vscode-integration`
#### CLI integration tests
#### Running CLI integration tests from the terminal
The CLI integration tests require the CodeQL standard libraries in order to run so you will need to clone a local copy of the `github/codeql` repository.
@@ -51,7 +52,7 @@ You will need to run tests using a task from inside of VS Code, under the "Run a
* View Tests: run the _Launch Unit Tests_ task
* VSCode integration tests: run the _Launch Unit Tests - No Workspace_ and _Launch Unit Tests - Minimal Workspace_ tasks
#### CLI integration tests
#### Running CLI integration tests from VSCode
The CLI integration tests require the CodeQL standard libraries in order to run so you will need to clone a local copy of the `github/codeql` repository.
@@ -63,7 +64,7 @@ The CLI integration tests require the CodeQL standard libraries in order to run
## Running a single test
### 1. From the terminal
### 1. Running a single test from the terminal
The easiest way to run a single test is to change the `it` of the test to `it.only` and then run the test command with some additional options
to only run tests for this specific file. For example, to run the test `test/vscode-tests/cli-integration/run-queries.test.ts`:
@@ -78,7 +79,7 @@ You can also use the `--testNamePattern` option to run a specific test within a
npm run test:cli-integration -- --runTestsByPath test/vscode-tests/cli-integration/run-queries.test.ts --testNamePattern "should create a QueryEvaluationInfo"
```
### 2. From VSCode
### 2. Running a single test from VSCode
Alternatively, you can run a single test inside VSCode. To do so, install the [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) extension. Then,
you will have quicklinks to run a single test from within test files. To run a single unit or integration test, click the "Run" button. Debugging a single test is currently only supported
@@ -94,7 +95,9 @@ Multi-Repo Variant Analyses (MRVA) rely on the GitHub API. In order to make deve
### Using a pre-recorded test scenario
To run a mock MRVA scenario, follow these steps:
1. Enable the mock GitHub API server by adding the following in your VS Code user settings (which can be found by running the `Preferences: Open User Settings (JSON)` VS Code command):
```json
"codeQL.mockGitHubApiServer":{
"enabled":true
@@ -108,9 +111,11 @@ To run a mock MRVA scenario, follow these steps:
If you want to replay the same scenario you should unload and reload it so requests are replayed from the start.
### Recording a new test scenario
To record a new mock MRVA scenario, follow these steps:
1. Enable the mock GitHub API server by adding the following in your VS Code user settings (which can be found by running the `Preferences: Open User Settings (JSON)` VS Code command):
```json
"codeQL.mockGitHubApiServer":{
"enabled":true
@@ -128,4 +133,4 @@ Once the scenario has been recorded, it's often useful to remove some of the req
### Scenario data location
Pre-recorded scenarios are stored in `./src/mocks/scenarios`. However, it's possible to configure the location, by setting the `codeQL.mockGitHubApiServer.scenariosPath` configuration property in the VS Code user settings.
Pre-recorded scenarios are stored in `./src/variant-analysis/github-api/mocks/scenarios`. However, it's possible to configure the location, by setting the `codeQL.mockGitHubApiServer.scenariosPath` configuration property in the VS Code user settings.
- Remove support for CodeQL CLI versions older than 2.9.4. [#2610](https://github.com/github/vscode-codeql/pull/2610)
- Implement syntax highlighting for the `additional` and `default` keywords. [#2609](https://github.com/github/vscode-codeql/pull/2609)
## 1.8.7 - 29 June 2023
- Show a run button on the file tab for query files, that will start a local query. This button will only show when a local database is selected in the extension. [#2544](https://github.com/github/vscode-codeql/pull/2544)
- Add a `CodeQL: Quick Evaluation Count` command to generate the count summary statistics of the results set
without spending the time to compute locations and strings. [#2475](https://github.com/github/vscode-codeql/pull/2475)
## 1.8.6 - 14 June 2023
- Add repositories to a variant analysis list with GitHub Code Search. [#2439](https://github.com/github/vscode-codeql/pull/2439) and [#2476](https://github.com/github/vscode-codeql/pull/2476)
## 1.8.5 - 6 June 2023
- Add settings `codeQL.variantAnalysis.defaultResultsFilter` and `codeQL.variantAnalysis.defaultResultsSort` for configuring how variant analysis results are filtered and sorted in the results view. The default is to show all repositories, and to sort by the number of results. [#2392](https://github.com/github/vscode-codeql/pull/2392)
- Fix bug to ensure error messages have complete stack trace in message logs. [#2425](https://github.com/github/vscode-codeql/pull/2425)
- Fix bug where the `CodeQL: Compare Query` command did not work for comparing quick-eval queries. [#2422](https://github.com/github/vscode-codeql/pull/2422)
- Update text of copy and export buttons in variant analysis results view to clarify that they only copy/export the selected/filtered results. [#2427](https://github.com/github/vscode-codeql/pull/2427)
- Add warning when using unsupported CodeQL CLI version. [#2428](https://github.com/github/vscode-codeql/pull/2428)
- Retry variant analysis results download if connection times out. [#2440](https://github.com/github/vscode-codeql/pull/2440)
## 1.8.4 - 3 May 2023
- Avoid repeated error messages when unable to monitor a variant analysis. [#2396](https://github.com/github/vscode-codeql/pull/2396)
- Fix bug where a variant analysis didn't display the `#select` results set correctly when the [query metadata](https://codeql.github.com/docs/writing-codeql-queries/about-codeql-queries/#query-metadata) didn't exactly match the query results. [#2395](https://github.com/github/vscode-codeql/pull/2395)
- On the variant analysis results page, show the count of successful analyses instead of completed analyses, and indicate the reason why analyses were not successful. [#2349](https://github.com/github/vscode-codeql/pull/2349)
- Fix bug where the "CodeQL: Set Current Database" command didn't always select the database. [#2384](https://github.com/github/vscode-codeql/pull/2384)
## 1.8.3 - 26 April 2023
- Added ability to filter repositories for a variant analysis to only those that have results [#2343](https://github.com/github/vscode-codeql/pull/2343)
- Add new configuration option to allow downloading databases from http, non-secure servers. [#2332](https://github.com/github/vscode-codeql/pull/2332)
- Remove title actions from the query history panel that depended on history items being selected. [#2350](https://github.com/github/vscode-codeql/pull/2350)
## 1.8.2 - 12 April 2023
- Fix bug where users could end up with the managed CodeQL CLI getting uninstalled during upgrades and not reinstalled. [#2294](https://github.com/github/vscode-codeql/pull/2294)
- Fix bug that was causing code flows to not get updated when switching between results. [#2288](https://github.com/github/vscode-codeql/pull/2288)
- Restart the CodeQL language server whenever the _CodeQL: Restart Query Server_ command is invoked. This avoids bugs where the CLI version changes to support new language features, but the language server is not updated. [#2238](https://github.com/github/vscode-codeql/pull/2238)
- Avoid requiring a manual restart of the query server when the [external CLI config file](https://docs.github.com/en/code-security/codeql-cli/using-the-codeql-cli/specifying-command-options-in-a-codeql-configuration-file#using-a-codeql-configuration-file) changes. [#2289](https://github.com/github/vscode-codeql/pull/2289)
## 1.8.1 - 23 March 2023
- Show data flow paths of a variant analysis in a new tab. [#2172](https://github.com/github/vscode-codeql/pull/2172) & [#2182](https://github.com/github/vscode-codeql/pull/2182)
@@ -28,7 +28,7 @@ For information about other configurations, see the separate [CodeQL help](https
1. [Run a query](#running-a-query).
---
<!-- markdownlint-disable-next-line MD024 -->
## Quick start: Installing and configuring the extension
### Installing the extension
@@ -71,6 +71,7 @@ in the starter workspace directory.
If you're using your own clone of the CodeQL standard libraries, you can do a `git pull` from where you have the libraries checked out.
<!-- markdownlint-disable-next-line MD024 -->
## Quick start: Using CodeQL
You can find all the commands contributed by the extension in the Command Palette (**Ctrl+Shift+P** or **Cmd+Shift+P**) by typing `CodeQL`, many of them are also accessible through the interface, and via keyboard shortcuts.
"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."
"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.runningQueries.numberOfThreads":{
"type":"integer",
@@ -203,8 +247,8 @@
},
"codeQL.runningQueries.autoSave":{
"type":"boolean",
"default":false,
"description":"Enable automatically saving a modified query file when running a query."
"description":"Enable automatically saving a modified query file when running a query.",
"markdownDeprecationMessage":"This property is deprecated and no longer has any effect. To control automatic saving of documents before running queries, use the `debug.saveBeforeStart` setting."
},
"codeQL.runningQueries.maxQueries":{
"type":"integer",
@@ -287,12 +331,65 @@
"patternErrorMessage":"Please enter a valid GitHub repository",
"markdownDescription":"[For internal use only] The name of the GitHub repository in which the GitHub Actions workflow is run when using the \"Run Variant Analysis\" command. The repository should be of the form `<owner>/<repo>`)."
},
"codeQL.variantAnalysis.defaultResultsFilter":{
"type":"string",
"default":"all",
"enum":[
"all",
"withResults"
],
"enumDescriptions":[
"Show all repositories in the results view.",
"Show only repositories with results in the results view."
],
"description":"The default filter to apply to the variant analysis results view."
},
"codeQL.variantAnalysis.defaultResultsSort":{
"type":"string",
"default":"numberOfResults",
"enum":[
"alphabetically",
"popularity",
"mostRecentCommit",
"numberOfResults"
],
"enumDescriptions":[
"Sort repositories alphabetically in the results view.",
"Sort repositories by popularity in the results view.",
"Sort repositories by most recent commit in the results view.",
"Sort repositories by number of results in the results view."
],
"description":"The default sorting order for repositories in the variant analysis results view."
},
"codeQL.logInsights.joinOrderWarningThreshold":{
"type":"number",
"default":50,
"scope":"window",
"minimum":0,
"description":"Report a warning for any join order whose metric exceeds this value."
},
"codeQL.databaseDownload.allowHttp":{
"type":"boolean",
"default":false,
"description":"Allow database to be downloaded via HTTP. Warning: enabling this option will allow downloading from insecure servers."
},
"codeQL.createQuery.qlPackLocation":{
"type":"string",
"patternErrorMessage":"Please enter a valid folder",
"markdownDescription":"The name of the folder where we want to create queries and QL packs via the \"CodeQL: Create Query\" command. The folder should exist."
},
"codeQL.createQuery.autogenerateQlPacks":{
"type":"string",
"default":"ask",
"enum":[
"ask",
"never"
],
"enumDescriptions":[
"Ask to create a QL pack when a new CodeQL database is added.",
"Never create a QL pack when a new CodeQL database is added."
],
"description":"Ask the user to generate a QL pack when a new CodeQL database is downloaded."
"contents":"You have no query history items at the moment.\n\nSelect a database to run a CodeQL query and get your first results."
},
{
"view":"codeQLQueries",
"contents":"Looking for queries..."
},
{
"view":"codeQLDatabases",
"contents":"Add a CodeQL database:\n[From a folder](command:codeQLDatabases.chooseDatabaseFolder)\n[From an archive](command:codeQLDatabases.chooseDatabaseArchive)\n[From a URL (as a zip file)](command:codeQLDatabases.chooseDatabaseInternet)\n[From GitHub](command:codeQLDatabases.chooseDatabaseGithub)"
`This feature requires CodeQL CLI version ${CliVersionConstraint.CLI_VERSION_WITH_QLPACKS_KIND.format()} or later.`,
);
return;
}
constmodelFile=awaitpickExtensionPack(
this.cliServer,
db,
this.app.logger,
progress,
token,
);
if(!modelFile){
return;
}
constview=newDataExtensionsEditorView(
this.ctx,
this.app,
this.databaseManager,
this.cliServer,
this.queryRunner,
this.queryStorageDir,
db,
modelFile,
);
awaitview.openView();
},
{
title:"Opening Data Extensions Editor",
},
);
},
};
}
privateasyncinitialize():Promise<void>{
awaitensureDir(this.queryStorageDir);
}
}
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.
