-
Notifications
You must be signed in to change notification settings - Fork 363
Produce separate SARIF file for quality-queries
alerts
#2935
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
87b6687
to
fe76653
Compare
const response = await client.request(target, { | ||
owner: repositoryNwo.owner, | ||
repo: repositoryNwo.repo, | ||
data: payload, | ||
}); |
Check warning
Code scanning / CodeQL
File data in outbound network request Medium
file data
2bf7322
to
24e4f58
Compare
7e59f77
to
f7fbaa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 andUploadTarget
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 whenquality-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 theisSarif
filter whensarifPath
is a single file. This can lead to uploading unwanted files (e.g., a.quality.sarif
when targeting code-scanning). ApplyisSarif
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"
3393b4e
to
81969d7
Compare
4088317
to
b403ba2
Compare
b403ba2
to
79049d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 function resolveQuerySuiteAlias( | ||
language: Language, | ||
query: string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I think should be named suite
instead of query
, but if there's precedence for using the query
name elsewhere, then just keep it.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
databaseRunQueries( | ||
databasePath: string, | ||
flags: string[], | ||
queries?: string[], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this deserves a jsdoc comment.
I'm guessing that the semantics is that she CLI will magically look up the query suite to use if nothing explicitly is provided by the user, and not that it will run zero queries.
@@ -306,12 +306,19 @@ function getAutomationID( | |||
return api.computeAutomationID(analysis_key, environment); | |||
} | |||
|
|||
// Enumerates API endpoints that accept SARIF files. | |||
export enum SARIF_UPLOAD_TARGET { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: SARIF_UPLOAD_ENDPOINT
is a more standard naming scheme for <method> <path>
strings like this.
export const qualityIsSarif = (name: string) => name.endsWith(".quality.sarif"); | ||
export const defaultIsSarif = (name: string) => | ||
name.endsWith(".sarif") && !qualityIsSarif(name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we move these definitions into UploadTarget
instances below, so you always access them through their associated target. I'd like a very strong coupling between the components of such targets to avoid a fragment being used wrongly.
That is: I love seeing sentinelPrefix: string = CodeScanningTarget.sentinelPrefix,
below rather than a direct reference to a codeScanningSentinelPrefix
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like to see this config pattern used here. Good choice.
sentinelPrefix: string; | ||
} | ||
|
||
// Represents the Code Scanning upload target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
,
export interface UploadTarget { | ||
name: string; | ||
target: SARIF_UPLOAD_TARGET; | ||
sarifFilter: (name: string) => boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: a filter
is typically a function of Array -> SubsetArray
, whereas this is a predicate
. The relation being that a filter is instantiated with a predicate.
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:database interpret-results
for queries that were specified as arguments to thequality-queries
input (if any). This results in SARIF files for those queries.Notes
quality-queries
alerts.query-filter
options with respect to code quality results.Merge / deployment checklist