| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I have had an initial look over this. It looks like a more involved change than I had hoped -- I was hoping we could just check the environment variable once we have the post-processed SARIF, just before uploading it, and then dump it to a file/folder.
This part of the Action is evolving quite a bit at the moment due to the work on Code Quality and I was planning to make a bunch of changes here in the next few days. They probably wouldn't interact nicely with these changes, though.
Sorry, something went wrong.
I had hoped that as well, but:
|
Sorry, something went wrong.
but in light of the other comments here, it makes sense to make that point to a directory instead |
Sorry, something went wrong.
We could still have code-scanning/code-quality folders inside our desired output dir. It's still a smaller dependency on internal path choices. |
Sorry, something went wrong.
we already have the .sarif / .quality.sarif discriminant for that. Pointing the env var to a directory is a good choice I think |
Sorry, something went wrong.
Setting it will cause the SARIF files that would be uploaded to be dumped to the specified directory as `upload.sarif` or `upload.quality.sarif`. Crucially, this happens even if uploads are disabled, which is useful for testing.
|
@mbg I tried a more surgical approach now (I recommend hiding whitespace in the diff view). I did like the fact that I had only one function in the lib processing the sarifs (as opposed to uploadFiles/uploadSpecifiedFiles), but I can understand it's more pragmatic to limit the changes done in the area, especially as it is a moving target with the Code Quality work. I still had to change the analyze action as well, because of the requirement to dump the SARIF file if requested even if upload: false. |
Sorry, something went wrong.
There was a problem hiding this comment.
This PR implements a new internal testing feature that allows dumping of processed SARIF files to a local directory via the CODEQL_ACTION_SARIF_DUMP_DIR environment variable. The feature works regardless of whether upload is enabled or disabled, making it useful for testing what gets sent to Code Scanning or Code Quality after SARIF processing.
Key changes:
Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/upload-lib.ts | Refactored upload functions to support conditional processing and added SARIF dumping functionality |
| src/environment.ts | Added new environment variable for SARIF dump directory |
| src/analyze-action.ts | Updated to use conditional upload functions and handle optional upload results |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for simplifying this, it's really appreciated!
I think there are fundamentally two things going on in this PR:
Perhaps it would be sensible to split these two aspects up into separate changes:
Sorry, something went wrong.
Fair enough, here's the PR 🙂 : |
Sorry, something went wrong.
|
@mbg should we maybe chat about this again? I thought that maybe we could add a special dry-run value to the upload option to drive this, independently of the internal dump variable. Passing dry-run would mean the same thing as always, save for skipping the actual final download. |
Sorry, something went wrong.
|
Obsoleted by: |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This introduces a CODEQL_ACTION_SARIF_DUMP_DIR environment variable for internal use that causes the processed SARIF file that codeql-action would upload to Code Scanning or Code Quality to be dumped locally. Crucially, this will also happen on analyze with upload: never.
This will allow us to test what is actually sent for upload after the SARIF processing that upload-lib.ts does (validating, merging, filtering, adding fingerprints etc.).
This SARIF file will be dumped in the directory specified by the environment variable, with upload.sarif or upload.quality.sarif as name. There is a risk of naming conflict if an output SARIF file has that name (which depends on the category), but I'm deeming it low risk (and not happening for our testing usage, where the file names are language names).
Risk assessment
For internal use only. Please select the risk level of this change:
Merge / deployment checklist