| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Looks like a sensible renaming, thanks! That --search-path use should probably be --additional-packs, and could probably be more specifically scoped to the path of the custom query within the repo, but for now I agree with preserving it for simplicity. As we discussed internally, let's hold off on deprecating the Runner's checkout-path flag for now, since it's widely used, in favour of giving users a path towards using the CLI instead. |
Sorry, something went wrong.
|
@adityasharad shall we merge this PR? |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Merge / deployment checklist
A discussion on #607 made me realise that the variable name checkoutPath is used for two purposes:
This pull request changes the variable name checkoutPath to be workspacePath when used for resolving paths, and sourceRoot whenever it is used as a CodeQL source-root.
There is a third use of the checkoutPath. It is passed to codeql as --search-path when running a custom query in the repository being analysed. I think this make little sense because it is very unlikely that the root folder of the repository we're analysing (or the workspace path) contains a query pack.
@adityasharad The discussion on #607 also made it clear that there is a slight inconsistency between the way the Action and the Runner handle the resolution of relative paths. The Runner resolves them with respect to the --checkout-path flag and the Action resolves them against ${GITHUB_WORKSPACE} (aka the working directory).
To make the Action and the Runner align better, I suggest we deprecate the --checkout-path flag and replace it with --source-root and --working-directory (both optional like --checkout-path and defaulting to .) . This should match the codeql cli terminology and in addition makes the Action and the Runner behave more similar.