fix(sentinel): upload the SARIF it just wrote - #1497
Merged
Conversation
Both upload steps were guarded by hashFiles() on a RUNNER_TEMP path. hashFiles resolves against the workspace and cannot see that directory, so the guard was false on every run and the SARIF was never uploaded - including the runs that found something. The scan step now reports whether it wrote the file, and the uploads key off that. The verdict is unchanged: the exit code is captured, the flag recorded, and the step still exits with it, so an infected main still fails the run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The sentinel's two SARIF upload steps have never run.
Both were guarded by:
hashFiles()resolves paths againstGITHUB_WORKSPACEand cannot seerunner.temp, so it returnedempty on every run and both uploads skipped — whether or not the file had been written.
The last run shows it plainly: the scan wrote the file, and the artifact step was skipped anyway.
That fails exactly when it matters most: step 6 tells the reader findings are "delivered via the run
log, the SARIF build artifact below, and
--alert" — and one of those three has never existed.Fix
The scan step reports whether it wrote the file, and the uploads key off that instead of a check that
cannot see the path:
The verdict is unchanged
The exit code is captured, the flag recorded, then the step exits with it — so an infected
mainstill fails the run exactly as before. The
always()guards stay, which is what lets the uploadhappen despite that non-zero exit.