Autodetect what language a query is for#915
Conversation
c17caba to
dac4201
Compare
aeisenberg
left a comment
There was a problem hiding this comment.
This looks right to me!
edoardopirovano
left a comment
There was a problem hiding this comment.
Mostly looks good apart from a minor comment inline. I'll hold off on approving it, though, since we paired on this for a bit so it should probably have another set of eyes.
adityasharad
left a comment
There was a problem hiding this comment.
Looks good! I think the code is mostly ready to go, with one outstanding suggestion from Edoardo about return types, and one from me about logging.
I've added some suggestions about tests, but I think those are fine to add later, since it will require some upfront work to set up tests for this part of the code.
Have we been adding changelog entries for this feature?
| * Resolves the language for a query. | ||
| * @param queryUri The URI of the query | ||
| */ | ||
| async resolveQueryByLanguage(workspaces: string[], queryUri: Uri): Promise<QueryInfoByLanguage> { |
There was a problem hiding this comment.
Since you asked about tests:
extensions/ql-vscode/src/vscode-tests/cli-integration/run-cli.test.tsis a good place to add integration tests for theresolveQueryByLanguageandresolveLanguagesfunctions.- You can use the existing tests as an example.
resolveLanguagesis probably easier to write a test for because there's no query as input.resolveQueryByLanguagewill require a test query: there are some examples in thedatafolders, but as far as I can tell none of them depend on an actual language. So you may need to add one, or save this test for later.
| * Finds the language that a query targets. | ||
| * If it can't be autodetected, prompt the user to specify the language manually. | ||
| */ | ||
| export async function findLanguage( |
There was a problem hiding this comment.
Since you asked about tests: I agree that having tests for this function would be handy, and give you confidence in its behaviour. However we don't yet have a test module for run-remote-query due to the experimental nature of the entire feature, so adding a test requires some upfront work. (In future it will be easier :) )
I'll record some pointers here about how you could create those tests, but I'm not expecting you to do it in this PR. We can look at test coverage together after this PR.
- For integration tests (which use a real query and actually run the underlying commands), copy
extensions/ql-vscode/src/vscode-tests/cli-integration/queries.test.tsas a template. I think it would make sense to have:- one test function that runs
findLanguageon a query with a real language dependency and identifies the language - one test function that runs it on a dummy query and returns
undefined - any other cases you can think of
- one test function that runs
- For unit tests (which don't run the actual commands, but simulate the underlying behaviour), use
extensions/ql-vscode/src/vscode-tests/no-workspace/query-results.test.tsas a template. Those tests mock the behaviour of the CLI server.
Also use autodection in relevant places - When running on multiple databases - When running a remote query
- Tweak return types + logging - Update changelog
b8a90b7 to
83c68ec
Compare
|
Thank you for the reviews ✨ I've addressed the main comments in 83c68ec and added a minimal changelog entry that covers the user-facing part of this. I'll look at adding tests in a separate PR! |
edoardopirovano
left a comment
There was a problem hiding this comment.
A couple more minor comments, but otherwise looks good!
| return; | ||
| } | ||
| } | ||
| const quickPickItems = filteredDBs.map<DatabaseQuickPickItem>(dbItem => ( |
There was a problem hiding this comment.
Note that if the user has no databases and doesn't pick a language when prompted, we try to display this prompt with nothing in it. There should probably be an extra check to display an error in this case and return, similarly to what happens with the filtered list above.
There was a problem hiding this comment.
Woops, good point! Thanks 😄
| const repositories = config.repositories; | ||
|
|
||
| if (!language) { | ||
| return; |
There was a problem hiding this comment.
I would add a brief comment stating that we don't need an error message here because findLanguage already displays one.
edoardopirovano
left a comment
There was a problem hiding this comment.
Thanks for addressing all my comments, this LGTM 👍🏼
Adds a
findLanguagefunction that usescodeql resolve queries --format bylanguageto detect a query's language. This might not work for some queries, so I've added a manual selection as a fallback.This is used in two places:
.repositoriesconfig. This config file is going to be replaced by a different UI soon.)Question: Does this need tests? I wasn't sure where/how to go about that!
Checklist
@github/docs-content-codeqlhas been cc'd in all issues for UI or other user-facing changes made by this pull request.