Add ignoredWorkspaceFolders setting

[gsingh93]

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.

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-review label there.

[robertbrignull]

This applies to more than just extension packs and would affect everywhere that the extension tries to discover files in the workspace. So it's quite a big change, but not necessarily a bad once and I'm not opposed to it. It could be quite useful for certain cases when you have very large workspace folders that you want to ignore.

[robertbrignull]

I suggest we rename to codeQL.runningQueries.ignoredWorkspaceFolders. It's a bit longer but it makes it clear just from the name that it only applies to workspace folders and not to arbitrary folders.

[gsingh93]

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]

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]

Ping @robertbrignull. Anything else you need from me?

[robertbrignull]

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]

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.