Produce separate SARIF file for quality-queries alerts

[mbg]

Follows on from #2917.

This PR modifies the action to produce separate SARIF files for code quality queries (as specified as arguments to the quality-queries input) and uploads them to the code quality API. The approach here is that:

• We remove the logic from Add new quality-queries input #2917 that adds the quality-queries input to the code scanning configuration file that's used when initialising the database.
• That means that the quality queries are no longer included in the config-queries.qls that's generated by the CLI.
• When we call database run-queries, and if quality queries are enabled, we explicitly specify config-queries.qls (which the CLI normally does by default if nothing is specified) + the quality queries.
• Since the quality queries are only specified as argument to database run-queries, the existing call to database interpret-results generates a SARIF that only includes results relating to security queries (i.e. config-queries.qls).
• We make an additional call to database interpret-results for queries that were specified as arguments to the quality-queries input (if any). This results in SARIF files for those queries.
• We then upload them to the CQ API endpoint.

Notes

• The changes aim to be as backwards-compatible as possible. That includes:
  • SARIF files are output to the same place as before (e.g. as opposed to having separate subdirectories for security and quality SARIFs). SARIF files containing quality results are identified by the .quality.sarif extension.
• We don't support query-filter options with respect to code quality results.

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 enables separate generation and upload of SARIF files for code-quality queries specified via the quality-queries input, in addition to the existing code-scanning SARIF flow.

• Introduces SARIF_UPLOAD_TARGET enum and UploadTarget interface to distinguish code scanning vs. code quality uploads.
• Extends file discovery (findSarifFilesInDir, getSarifFilePaths) and upload logic (uploadFiles, uploadPayload, validateUniqueCategory) to filter and handle .quality.sarif files.
• Updates analyze.ts/analyze-action.ts to produce and upload quality SARIFs when quality-queries are provided, and adjusts CI workflows to upload/check both SARIF artifacts.

Reviewed Changes

Copilot reviewed 12 out of 17 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/upload-lib.ts	Added enum and targets for separate SARIF uploads, filtering logic for .quality.sarif.
src/upload-lib.test.ts	Added tests for filtering .quality.sarif files and validateUniqueCategory prefix.
src/analyze.ts	Introduced default query suites and resolveQuerySuiteAlias; generate quality SARIF.
src/analyze.test.ts	Added tests for resolveQuerySuiteAlias.
src/analyze-action.ts	Uploads quality SARIF and sets quality-sarif-id output when quality-queries present.
pr-checks/checks/quality-queries.yml	CI updates to upload security vs. quality SARIF artifacts and adjust checks.

Comments suppressed due to low confidence (2)

src/upload-lib.ts:427

• The getSarifFilePaths function bypasses the isSarif filter when sarifPath is a single file. This can lead to uploading unwanted files (e.g., a .quality.sarif when targeting code-scanning). Apply isSarif to the single-file case or throw if it does not match.

    sarifFiles = [sarifPath];

pr-checks/checks/quality-queries.yml:29

• [nitpick] The CI step now only checks config properties in the quality SARIF, omitting the original security SARIF check. Consider adding a separate check for ${{ runner.temp }}/results/javascript.sarif to ensure both artifacts are validated.

      SARIF_PATH: "${{ runner.temp }}/results/javascript.quality.sarif"

[esbena]

Nice, and pleasantly surgical.

I think this does the right thing, except for a missing quality.sarif predicate in the very end.

Other than that it's mostly nits, and some concerns about maintenance in the long term. We have already discussed them elsewhere. Perhaps we should update the discussion document with our current choice for query resolution.

[esbena]

regarding the target/endpoint comment above: this is a much better place to call something target. I'd probably prefer SarifUploadConfig but that is splitting hairs.

[esbena]

Stray thought. I have seen both line comments and jsdoc comments on your new functions. Is it deliberate that you do not use jsdoc here? If yes, OK.

[mbg]

I think the existing codebase is fairly inconsistent in this regard. I probably just subconsciously mirrored what adjacent definitions do. I'll make this more consistent for my changes.

[esbena]

thanks! There's one naming nit left, but it is quite minor.

[esbena]

Suggested change

	export enum SARIF_UPLOAD_ENDPOINT {
	CODE_SCANNING_UPLOAD_TARGET = "PUT /repos/:owner/:repo/code-scanning/analysis",
	CODE_QUALITY_UPLOAD_TARGET = "PUT /repos/:owner/:repo/code-quality/analysis",
	}
	export enum SARIF_UPLOAD_ENDPOINT {
	CODE_SCANNING = "PUT /repos/:owner/:repo/code-scanning/analysis",
	CODE_QUALITY = "PUT /repos/:owner/:repo/code-quality/analysis",
	}