Extract directly to the toolcache - #2631
Conversation
Sorry, something went wrong.
dbartol
left a comment
There was a problem hiding this comment.
LGTM. Looks like a relatively simple change, plus some plumbing to pass the destination directory through to all the places the write the files.
On a GitHub-hosted runner, it looks like we'll still add the bundle to the toolcache, even though the cache will disappear after the job. Is this just because we have to put it somewhere, and we might as well put it in the toolcache for consistency with the less-common self-hosted runner scenario?
Sorry, something went wrong.
Yes, pretty much. It's also consistent with the situation where the GitHub-hosted runner images have caught up to the latest version of CodeQL and the tools we want are already installed. Plus if anyone's still using a hardcoded toolcache path to find CodeQL, that'll still work. |
Sorry, something went wrong.
NlightNFotis
left a comment
There was a problem hiding this comment.
Great!
Thank you for this change!
Sorry, something went wrong.
Adding the CodeQL Bundle to the toolcache seems to take a surprisingly long amount of time. We haven't collected large scale telemetry yet, but here's some anecdotal numbers from looking at the logs on PR checks:
Therefore in this PR, we add a feature flag that extracts the CodeQL bundle directly to the toolcache, eliminating the copy to toolcache step completely.
I've tested the change by adding a PR check, temporarily modifying this to running 10 runs on each platform, and running this a bunch of times. Next steps are dogfooding this change internally using the feature flag.
Merge / deployment checklist