Import testproj databases into workspace storage
Commit-by-commit review is recommended.
If a folder that ends with .testproj is encountered, assume it is a
database created by a codeql test. When the user wants to import this
database, copy it into workspace storage. The database can be
re-imported, which first removes the old version before importing it
again.
Ask user if they want to re-import outdated testproj dbs
Before running a query now, do the following:
- Check if the selected database is imported from a testproj
- If so, check the last modified time of the
codeql-datase.ymlfile of the imported database with that of its origin. - If the origin database has a file that is newer, assume that the database has been recreated since the last time it was imported.
- If newer, then ask the user if they want to re-import before running the query.
Also, this change appends the (test) label to all test databases in
the database list.
To verify this change, do the following:
- In the development workspace directory, create a codeql test:
echo "import javascript select 1" | tee test.ql echo "dependencies: codeql/javascript-all: \"*\" extractor: javascript tests: test" echo hucairz | tee qlpack.yml - Start the vscode dev workbench
- In the vscode editor, go to the test tab (looks like a beaker)
- Run the test. It should fail
- Right click on the
test.testprojdirectory and select "(Re-)Import test database" - Notice that the database is imported
- Run the query if you like and you should see
1as the result. - Change test to
select 2 - Re-run the test
- Re-run the query
- This time, you should get a popup asking if you want to re-import
- Select
yes - See the results are now
2.
Checklist
- [ ] CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
- [ ] Issues have been created for any UI or other user-facing changes made by this pull request.
- [ ] [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the
ready-for-doc-reviewlabel there.
I'm not sure what's happening with the EPERM errors when renaming the directory on windows. It must be that the OS is hanging on to an open file handle somewhere, somehow, but I don't know where this would be happening. I could try to add a 1 second wait before renaming in case there's some sort of cleanup that needs to finish, but that feels very unsatisfactory.
Two possibilities come to mind:
- If you've just created the copy, then Defender might be scanning the newly-created files.
- Does an existing CodeQL process have a lock on the DB?
The next thing to try would be to add a few second wait on windows.
OK...that seems to have worked, but it's not a great solution.
Thanks for such a detailed review, Koen!