Produce separate SARIF file for quality-queries alerts
#2935
Conversation
87b6687 to
fe76653
Compare
2bf7322 to
24e4f58
Compare
7e59f77 to
f7fbaa0
Compare
There was a problem hiding this comment.
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_TARGETenum andUploadTargetinterface to distinguish code scanning vs. code quality uploads. - Extends file discovery (
findSarifFilesInDir,getSarifFilePaths) and upload logic (uploadFiles,uploadPayload,validateUniqueCategory) to filter and handle.quality.sariffiles. - Updates
analyze.ts/analyze-action.tsto produce and upload quality SARIFs whenquality-queriesare 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
getSarifFilePathsfunction bypasses theisSariffilter whensarifPathis a single file. This can lead to uploading unwanted files (e.g., a.quality.sarifwhen targeting code-scanning). ApplyisSarifto 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.sarifto ensure both artifacts are validated.
SARIF_PATH: "${{ runner.temp }}/results/javascript.quality.sarif"
3393b4e to
81969d7
Compare
4088317 to
b403ba2
Compare
b403ba2 to
79049d9
Compare
There was a problem hiding this comment.
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.
| export const defaultSuites: Set<string> = new Set([ | ||
| "security-experimental", | ||
| "security-extended", | ||
| "security-and-quality", | ||
| "code-quality", | ||
| "code-scanning", | ||
| ]); |
There was a problem hiding this comment.
This is my least favorite part of the PR. As it leads to double maintenance.
It would be great if the same resolution that the ordinary .queries uses could be reused here. In the interest of time, we don't need to do it right now though. Could you perhaps create an issue with a list of things to follow up on later?
There was a problem hiding this comment.
I agree that having this in the action isn't great - this is one of the bits I was thinking of yesterday when we were talking. I'll create an issue for it.
| @@ -567,6 +581,30 @@ export function buildPayload( | |||
| return payloadObj; | |||
| } | |||
|
|
|||
| // Represents configurations for different services that we can upload SARIF to. | |||
| export interface UploadTarget { | |||
There was a problem hiding this comment.
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.
| sentinelPrefix: string; | ||
| } | ||
|
|
||
| // Represents the Code Scanning upload target. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/upload-sarif-action.ts
Outdated
| features, | ||
| logger, | ||
| ); | ||
| core.setOutput("sarif-id", uploadResult.sarifID); | ||
|
|
||
| // If there are `.quality.sarif` files in `sarifPath`, then upload those to the code quality service. | ||
| const qualitySarifFiles = upload_lib.getSarifFilePaths(sarifPath); |
There was a problem hiding this comment.
Bug: getSarifFilePaths(sarifPath); is this missing a quality specialization through some argument, or is there some hidden state elsewhere?
I think this should be getSarifFilePaths(sarifPath, upload_lib.CodeQualityTarget.sarifFilter),
There was a problem hiding this comment.
Probably more than the bug itself, this shows that there's lacking test coverage for this part. I will see what I can add without too much refactoring, or track the need for this in an issue.
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-queriesinput) and uploads them to the code quality API. The approach here is that:database interpret-resultsfor queries that were specified as arguments to thequality-queriesinput (if any). This results in SARIF files for those queries.Notes
quality-queriesalerts.query-filteroptions with respect to code quality results.Merge / deployment checklist