Skip to content

Address unresolved PR #1 review comments; add tag-triggered releases - #2

Merged
DhakadG merged 2 commits into
mainfrom
fix/pending-review-comments
Aug 19, 2026
Merged

Address unresolved PR #1 review comments; add tag-triggered releases#2
DhakadG merged 2 commits into
mainfrom
fix/pending-review-comments

Conversation

@DhakadG

@DhakadG DhakadG commented Aug 19, 2026

Copy link
Copy Markdown
Owner

Two greptile-apps review 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.pyImage.MAX_IMAGE_PIXELS = None disabled 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.ymlactions/checkout@v4, actions/setup-python@v5, actions/upload-artifact@v4 were mutable tags. A retagged upstream release changes what a given commit runs, which matters here since this workflow produces unsigned, distributed .app bundles. Pinned all three to commit SHAs (version kept as a trailing comment).

Also new: .github/workflows/release.yml. Pushing a v*.*.* tag now builds both macOS bundles and publishes them to a GitHub Release via gh release create, rather than only the 14-day CI artifacts build.yml produces. 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

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
@coderabbitai

coderabbitai Bot commented Aug 19, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@DhakadG, you've reached your PR review limit, so we couldn't start this review.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d4af8748-fd8e-4b04-bdb8-1cf3514e64f2

📥 Commits

Reviewing files that changed from the base of the PR and between 72c1993 and 50fc102.

📒 Files selected for processing (5)
  • .github/workflows/build.yml
  • .github/workflows/release.yml
  • README.md
  • core/imaging.py
  • tests/test_engine.py

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@greptile-apps

greptile-apps Bot commented Aug 19, 2026

Copy link
Copy Markdown

Greptile Summary

The PR resolves the two prior review findings and adds tag-triggered macOS releases.

  • Passes release tag names through a quoted environment variable instead of interpolating them into shell source.
  • Enforces the 300-million-pixel limit explicitly before image decoding.
  • Pins workflow actions to immutable commits and adds release documentation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

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

Comment thread .github/workflows/release.yml
Comment thread core/imaging.py
- 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
@DhakadG
DhakadG merged commit 4ab1d17 into main Aug 19, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants