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.
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.
