There was a problem hiding this comment.
This PR refactors the upload-sarif flow to avoid potentially initializing the CodeQL CLI more than once by moving CodeQL acquisition/initialization earlier and threading a shared CodeQL getter + temp directory through SARIF post-processing.
Changes:
Copilot reviewed 7 out of 11 changed files in this pull request and generated 3 comments.
Show a summary per file| src/upload-sarif.ts | Threads tempPath + getCodeQL into SARIF post-processing. |
| src/upload-sarif.test.ts | Updates stubs/calls to match the new postProcessAndUploadSarif signature. |
| src/upload-sarif-action.ts | Adds cached CodeQL initialization and ensures temp dir/config are determined up front. |
| src/upload-lib.ts | Introduces minimalInitCodeQL, adds CodeQLGetter, and propagates getter/temp dir into CLI SARIF combining + upload flow. |
| src/init-action-post-helper.ts | Updates failed-SARIF upload to pass tempDir + codeql into uploadFiles. |
| src/init-action-post-helper.test.ts | Adjusts expectations for updated uploadFiles signature. |
| src/analyze-action.ts | Passes config.tempDir and a CodeQLGetter into postProcessAndUploadSarif. |
Sorry, something went wrong.
There was a problem hiding this comment.
Looks good, but do we actually have a PR check that tests this behaviour? It would need to:
Sorry, something went wrong.
| sarifFiles: string[], | ||
| gitHubVersion: GitHubVersion, | ||
| features: FeatureEnablement, | ||
| _features: FeatureEnablement, |
There was a problem hiding this comment.
Drive-by cleanup: Remove this arg?
Sorry, something went wrong.
|
Looks good, but do we actually have a PR check that tests this behaviour? It would need to:
I added some unit tests for getOrInitCodeQL which exercise the caching behaviour. Let me know if you think that's sufficient or you think we need something more comprehensive. We could add another language to the existing PR check for analysis kinds, which in some matrix jobs would then call combineSarifFilesUsingCLI twice. |
Sorry, something went wrong.
|
I added some unit tests for getOrInitCodeQL which exercise the caching behaviour. Let me know if you think that's sufficient or you think we need something more comprehensive. We could add another language to the existing PR check for analysis kinds, which in some matrix jobs would then call combineSarifFilesUsingCLI twice. Thanks for adding the unit tests. Updating one of the PR checks to exercise this functionality so we also have end-to-end tests would be my preference. |
Sorry, something went wrong.
There was a problem hiding this comment.
I added some unit tests for getOrInitCodeQL which exercise the caching behaviour. Let me know if you think that's sufficient or you think we need something more comprehensive. We could add another language to the existing PR check for analysis kinds, which in some matrix jobs would then call combineSarifFilesUsingCLI twice.
Thanks for adding the unit tests. Updating one of the PR checks to exercise this functionality so we also have end-to-end tests would be my preference.
(Copying into a review so I don't get pinged about outstanding reviews)
Sorry, something went wrong.
This is a fresh attempt at #3006 based on the suggestion in #3006 (review).
This wasn't a priority to fix, but I am working on something else that requires a CodeQL instance in upload-sarif and thought it would make sense to address this first.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
Products:
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist