Add new quality-queries input

[mbg]

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

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[Copilot]

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

Comments suppressed due to low confidence (3)

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)

[esbena]

Generally LGTM. Pending some related discussion in internal document.

[esbena]

• 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?...

[mbg]

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).

[esbena]

OK. Would a user want to know any of these subtleties? Alternative: Should the input perhaps be marked as internal for the time being?

[starcke]

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.

[mbg]

Alternative: Should the input perhaps be marked as internal for the time being?

Happy to mark as internal or experimental for now.

[mbg]

I have pushed a commit which marks it as internal.

[esbena]

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.

[mbg]

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.

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).