Add new quality-queries input - #2917
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a new quality-queries input to the init action and propagates it through configuration parsing and SARIF generation, enabling code quality queries to be combined and filtered alongside existing query inputs.
- Adds quality-queries to init-action.ts and action.yml
- Extends config-utils and codeql modules to parse and inject quality queries
- Updates unit tests and generated workflows to cover the new input
Reviewed Changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated no comments.
Show a summary per file| File | Description |
|---|---|
| src/init-action.ts | Propagate qualityQueriesInput from action inputs |
| src/config-utils.ts | Extend calculateAugmentation and related interfaces |
| src/config-utils.test.ts | Add qualityQueriesInput to test setup and cases |
| src/codeql.ts | Inject qualityQueriesInput into SARIF config building |
| init/action.yml | Declare new quality-queries input |
| pr-checks/checks/quality-queries.yml | Add PR check workflow for quality queries |
| lib/init-action.js | Build output for quality-queries handling |
| lib/config-utils.js | Compiled parsing and augmentation updates |
| lib/config-utils.test.js | Compiled test adjustments for quality queries |
| lib/codeql.js | Compiled SARIF injection updates |
| .github/workflows/__quality-queries.yml | Generated workflow for the new PR check |
src/config-utils.test.ts:860
- Add a test case where both queries and quality-queries inputs are provided together (with and without + prefix) to verify that they merge correctly into the resulting queriesInput and qualityQueriesInput properties.
// (after existing tests for quality queries)
Sorry, something went wrong.
esbena
left a comment
There was a problem hiding this comment.
Generally LGTM. Pending some related discussion in internal document.
Sorry, something went wrong.
| description: Comma-separated list of additional queries to run. By default, this overrides the same setting in a configuration file; prefix with "+" to use both sets of queries. | ||
| required: false | ||
| quality-queries: | ||
| description: Comma-separated list of code quality queries to run. |
There was a problem hiding this comment.
- Does this also support the + semantics of queries above?
- Does the user need to know what the difference is between these two inputs? What happens if a query is present in both? What if a non-quality query is present in the quality suite?...
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry, I thought I had replied to this.
Does this also support the + semantics of queries above?
No, I omitted that for now to keep it simple, but I can add it if we think it makes sense. AFAIK it's not something that we would be using internally right now.
Does the user need to know what the difference is between these two inputs?
In default setup, we provide the inputs. For advanced setup, the user can specify this. In the future, we might want a simpler "on" switch for quality queries, but I don't think that would change us wanting to have this.
What happens if a query is present in both?
Then the resulting alerts should go in both SARIF uploads.
What if a non-quality query is present in the quality suite?...
My understanding is that this isn't necessarily something we should be concerned with in the action right now. If we get an input to quality-queries, we should assume that those are quality queries. The backend filters out things that it doesn't think are quality queries (that's already happens, since the backend only gets one big SARIF file with all alerts right now).
Sorry, something went wrong.
There was a problem hiding this comment.
OK. Would a user want to know any of these subtleties? Alternative: Should the input perhaps be marked as internal for the time being?
Sorry, something went wrong.
There was a problem hiding this comment.
My understanding is that this isn't necessarily something we should be concerned with in the action right now. If we get an input to quality-queries, we should assume that those are quality queries. The backend filters out things that it doesn't think are quality queries (that's already happens, since the backend only gets one big SARIF file with all alerts right now).
This is correct, the backend filters the SARIF based on a list of quality queries it knows about.
Sorry, something went wrong.
There was a problem hiding this comment.
Alternative: Should the input perhaps be marked as internal for the time being?
Happy to mark as internal or experimental for now.
Sorry, something went wrong.
There was a problem hiding this comment.
I have pushed a commit which marks it as internal.
Sorry, something went wrong.
esbena
left a comment
There was a problem hiding this comment.
LGTM with the caveat that the splitting strategy for normal and quality queries still hasn't been done.
Depending on how that is done, the quality-queries and queries inputs may have to be propagated further into the action later, so the design now may as well take that into account.
The semantics now is simply that there's a secondary input to add queries through.
Sorry, something went wrong.
Yes, that will be in a separate PR. The inputs are propagated already through the configuration file that is restored in other steps (config.augmentationProperties.qualityQueriesInput is available later). |
Sorry, something went wrong.
This PR adds a new quality-queries input to the init action. Fundamentally, this behaves the same as the queries input and propagates a list of queries to the CLI. The list of queries given in the quality-queries input is combined with the queries input and configuration file, as expected.
The intention here is that this will later allow us to filter SARIF results depending on which input the query responsible for the alert belongs to.
Merge / deployment checklist