| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Project a review the caller already holds with the same closed rules as the CLI findings --sarif command, including locations, gaps, and refusals. Co-authored-by: Edmundo Sanchez <eddi@heyeddi.com>
| Back | FazBrowse Home | New Git URL |
What
review_sarif projects one retained pull-request review into a SARIF 2.1.0 document. Both clients already return the review; this is the closed projection the CLI writes with proofline findings --sarif.
Why
The CLI already defines this document for GitHub code scanning and other SARIF 2.1.0 consumers, and neither SDK exposes it, so every Python caller would have to rebuild the projection. The rules are easy to get wrong: a location counts only when it is a verified file at the reviewed head, an unknown severity or risk domain is refused, a partial CODE record still contributes findings but makes the invocation unsuccessful, and a withheld or off-commit CODE record contributes none.
The projection follows the CLI rather than inventing a second one:
A deployment, patch, or other subject, a head that is not a 40- or 64-character commit SHA, or a review id that does not match the record raises SarifExportError and returns no document.
No generated client, OpenAPI document, or workflow file is changed.
How it's tested
tests/test_sarif.py covers:
python3 scripts/check.py passed: generation freshness, operation contracts, ruff check, ruff format --check, mypy, pytest (143 passed), and wheel plus sdist install smoke tests.