Add support for running ML-powered queries for JS security-extended
behind ml_powered_queries
feature flag
#857
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR builds on #856 to add support for running ML-powered queries. Currently these queries would only be run for customers (a) performing JavaScript analysis, (b) running the
security-extended
(orsecurity-and-quality
) query suite, and (c) whose repos are opted into theml_powered_queries
feature flag.The action happens in
src/config-utils.ts
: when all of these conditions hold, we add thecodeql/javascript-experimental-atm-queries
pack to the analysis.Since the security review for this feature is not yet complete, these queries will currently return no results. We will not roll out the feature flag until this security review is complete to avoid needlessly increasing the runtime of customers' analyses by downloading the ML-powered query pack.
Points for review
We want to enable ML-powered queries based in part on which query suite the customer is running. We resolve query suites into query paths in the
init
action, and theanalysis
action to my knowledge doesn't know what query suites the user requested. Therefore theinit
action is the natural point to test whether we should run ML-powered queries.However this does necessitate an API call to test feature flag enablement in the
init
action as well as the existing one in theanalysis
action that's used for database upload.Another option is saving some kind of information (e.g. feature flags or the query suites requested) to the config file in the
init
action and loading them in theanalysis
action. I didn't go with this since it seems like overengineering for the benefit of one fewer API call, and the API call in consideration doesn't count towards rate limits, but what do reviewers think?Merge / deployment checklist