search

github / vscode-codeql

An extension for Visual Studio Code that adds rich language support for CodeQL
https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-codeql
MIT License
421 stars 184 forks source link

Add ignoredWorkspaceFolders setting #3617

Open gsingh93 opened 4 months ago

gsingh93 commented 4 months ago

This PR adds an ignoredFolders setting to the extension. Currently, getOnDiskWorkspaceFolders gets all root folders in a multi-root workspace to use for things like --additional-packs when invoking the CLI tool. This can cause major latency (multiple minutes) when the workspace folders are large. By ignoring these folders, the extension is significantly faster.

Another way to get the speed up is to add an empty codeql-workspace.yml in the root of the large workspace folder to prevent them from being searched, but I don't want to have to create this file every time I need to do this, as usually I can't add it to upstream projects.

I'll update the CHANGELOG once I get some confirmation this is OK to add.

image

Checklist

gsingh93 commented 4 months ago

Thanks @robertbrignull, I updated with the suggested name and included a line in the changelog. Let me know if you have any other feedback.

Regarding this line in the "Checklist", I'm not sure what needs to be done:

Issues have been created for any UI or other user-facing changes made by this pull request.

robertbrignull commented 4 months ago

Thanks for adding a changelog entry.

Regarding this line in the "Checklist", I'm not sure what needs to be done:

Issues have been created for any UI or other user-facing changes made by this pull request.

Don't worry about that. You can ignore it, and we will tidy up the PR template.

gsingh93 commented 3 months ago

Ping @robertbrignull. Anything else you need from me?

robertbrignull commented 3 months ago

I'm very sorry for the delay. We have now discussed this internally. Unfortunately we're not sure we want to go this route because the implementation looks more complicated than initially thought.

We don't always use getOnDiskWorkspaceFoldersObjects when dealing with workspace folders. It's a good helper method but there are a large number of places where we access workspace.workspaceFolders directly, including modifying it, and often needing the exact index of a certain element.

As well as the implementation cost it's also not fully clear if this config option is what we will want long term. Is it the right level of granularity or should it apply to things other than workspace folders? Unfortunately it would be hard to change later without breaking user's workspaces.

Overall we might have to ask you to keep using your workaround for now. If this continues to be a problem or if there are other users experiencing the same issue, we can revisit this.

gsingh93 commented 3 months ago

Thanks for the response. I think your concerns are reasonable. That being said, I'm wondering if there's any path forward for this by just focusing on codeql resolve library-path, which is the main source of the performance issues. Essentially, instead of modifying the global getOnDiskWorkspaceFoldersObjects, we just prevent certain folders from being added to --additional-packs when this resolve command is about to be executed. By scoping it down like this, we address the main issue without affecting other unrelated parts of the extension, and we make the setting name and description clear about exactly it applies to. If in the future we want to expand this to other parts of the extension, at least it wouldn't be a breaking change.

Overall we might have to ask you to keep using your workaround for now.

Funnily enough, the workaround started causing issues this morning. I think after I updated to 2.17.4, codeql complains when it sees an empty workspace file ([ERROR] resolve library-path> ERROR: File is empty.). I fixed it by changing the empty workspace file to just provides:, but this is an example of why relying on unofficially supported workarounds like this long-term is not a great idea. I also need to go make sure my colleagues are aware of this change now, as they don't really know any of the internals of how workspaces work or library paths are resolved, and would likely spend more time debugging this on their own.