Address unresolved PR #1 review comments; add tag-triggered releases - #2
Conversation
Two greptile-apps threads on PR #1 were never resolved (the 14 CodeRabbit findings were; these weren't caught in that pass): - core/imaging.py: Image.MAX_IMAGE_PIXELS was disabled outright. A folder can contain a downloaded or crafted file with an absurd declared size, not just the user's own camera scans. Raised it to 300M pixels instead of disabling it, so Pillow's decompression-bomb check still fires (and is caught per-file like any other conversion failure) while leaving real large scans well clear of the ceiling. - .github/workflows/build.yml: actions/checkout, setup-python and upload-artifact were pinned to mutable major-version tags, so a retagged upstream release changes what a given commit runs and what an unsigned distributable .app was built with. Pinned all three to commit SHAs (with the version kept as a trailing comment). Also adds .github/workflows/release.yml: pushing a v*.*.* tag builds both macOS bundles and publishes them to a GitHub Release via `gh release create`, instead of only the 14-day CI artifacts build.yml produces. README points at Releases first now and documents how to cut one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PRY53DANtDbuMuYEanvhGz
|
Warning Review limit reached
Next review available in: 34 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe PR resolves the two prior review findings and adds tag-triggered macOS releases.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| .github/workflows/release.yml | Safely handles the tag as a quoted environment-variable value while building and publishing both macOS artifacts. |
| core/imaging.py | Adds an explicit pre-decode pixel-count check that closes Pillow's warning-only range. |
| tests/test_engine.py | Adds boundary coverage confirming that pixel counts above the configured limit are rejected. |
| .github/workflows/build.yml | Pins third-party actions to immutable commit SHAs. |
| README.md | Documents downloadable releases and the tag-based release process. |
Reviews (2): Last reviewed commit: "Fix two P1 findings from Greptile's revi..." | Re-trigger Greptile
- release.yml: the publish step templated ${{ github.ref_name }} directly
into a run: block with contents: write. Actions substitutes that as literal
script text before bash ever sees it, so a tag containing shell metachars
(git tag names allow $, (, ), backticks — nothing in git-check-ref-format
forbids them) would execute inside the double-quoted string. Passed it
through env: TAG_NAME instead: the shell only ever sees it as a variable
value, never re-parsed as script.
- core/imaging.py: Pillow only *warns* (doesn't raise) for images between
1x and 2x MAX_IMAGE_PIXELS and still decodes them — so the 300M cap added
in the last commit had a silent 300M-600M gray zone where nothing actually
stopped the decode. Added an explicit check right after Image.open() reads
the header (before any pixel data is touched), so anything over the limit
is rejected the same way regardless of which side of Pillow's fuzzed
threshold it falls on. New test covers the gap directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PRY53DANtDbuMuYEanvhGz
Two
greptile-appsreview threads on #1 were never resolved — the "Address CodeRabbit review" commit fixed 14 CodeRabbit findings but didn't touch these two, from a different bot:core/imaging.py—Image.MAX_IMAGE_PIXELS = Nonedisabled Pillow's decompression-bomb guard entirely. Raised it to 300,000,000 px instead: comfortably clears real 100 MP camera scans and stitched panoramas, but a folder containing a downloaded or crafted file with an absurd declared size now fails cleanly per-file (DecompressionBombError, caught the same way any other conversion failure is) instead of risking an OOM..github/workflows/build.yml—actions/checkout@v4,actions/setup-python@v5,actions/upload-artifact@v4were mutable tags. A retagged upstream release changes what a given commit runs, which matters here since this workflow produces unsigned, distributed.appbundles. Pinned all three to commit SHAs (version kept as a trailing comment).Also new:
.github/workflows/release.yml. Pushing av*.*.*tag now builds both macOS bundles and publishes them to a GitHub Release viagh release create, rather than only the 14-day CI artifactsbuild.ymlproduces. README's "Prebuilt macOS app" section now points at Releases first, and documents how to cut one.python tests/test_engine.py— all 15 checks pass locally with the raised pixel cap.🤖 Generated with Claude Code
Generated by Claude Code