Repository navigation
fix(cmd): the SARIF names a nested finding's container in its message, never in a location outside the checkout - #583
Merged
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
thomasboni
force-pushed
the
fix/sarif-related-location-uri
branch
from
October 30, 2026 22:55
aa5af92 to
f4f2de2
Compare
…, never in a location outside the checkout GitHub Code Scanning rejects the WHOLE upload when any result location, a related one included, carries a URI whose scheme is not the checkout's: `SARIF URI scheme "https" did not match the checkout URI scheme "file"` (invoke-ai/InvokeAI run 41127816328, 2026-10-30, three nested ISSUE-307 findings pulled in via nschloe/action-cached-lfs-checkout). Since 0.7.x a nested finding carried the container line as a related location whose URI was the absolute blob URL, so every repository with one nested finding and `upload-sarif` on saw its job fail at the upload step. The container line now closes the result message as an embedded link to the blob URL (`(defined in [owner/action@ref, action.yml line N](url))`), the same section 3.11.6 syntax the message already uses for the issue code; the `url` property keeps the link for SARIF viewers. The result's one location stays the workflow step the user edits. A direct finding and a finding under a local outermost composite (ruling L2) are unchanged. Proven against Code Scanning itself on thomasboni/nested-actions-a: the 0.7.16 SARIF is refused with `unrecognized SARIF location URI scheme "https"` three times, the fixed one processes to `complete`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FUFtr3m8zC2mVNKVTQvaNz
thomasboni
force-pushed
the
fix/sarif-related-location-uri
branch
from
October 30, 2026 23:01
f4f2de2 to
493155a
Compare
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.
What breaks
Since the nested actions resolution (#549), a nested finding's SARIF result carried the container line as a related location whose URI was the absolute GitHub blob URL. GitHub Code Scanning rejects the whole upload when any location, related ones included, has a URI scheme other than the checkout's:
Seen on invoke-ai/InvokeAI (run 41127816328, 2026-10-30): three ISSUE-307 findings pulled in via
nschloe/action-cached-lfs-checkout, the upload step fails, the job fails even when the gate passes. Every repository with one nested finding andupload-sarifon is affected. It did not show on the outreach PR because fork PRs run with the upload disabled.The fix
(defined in [owner/action@ref, action.yml line N](blob url)). Theurlproperty keeps the link for SARIF viewers.relatedLocationsany more; the result's one location stays the workflow step the user edits.docs/GITHUB_ISSUES.md(ISSUE-701, ISSUE-703 sections) says what the SARIF carries now.Tests
TestBuildSARIF_NestedResultNamesTheContainerInTheMessage(red before the fix): no related location, no location URI with a scheme anywhere in the serialized log, the container link as the nested message's tail, the direct message untouched.make lint0 issues,make deadcodeonly the CI-exemptConfigSchemas,go vetclean,go test ./...green.E2E against Code Scanning itself
On
thomasboni/nested-actions-a(one nested finding chain), both SARIFs uploaded through the Code Scanning API for the same commit:failed:unrecognized SARIF location URI scheme "https"(three times)completeThe platform push uses the same SARIF builder, so platform mode is covered by the same change.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FUFtr3m8zC2mVNKVTQvaNz