chore(sandbox): add jless to sandbox image#232
Conversation
Install the latest jless from PaulJuliusMartinez/jless as part of the base image build (dynamic version lookup via the GitHub releases API).
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughThe Dockerfile modification installs Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 0/1 reviews remaining, refill in 43 minutes and 59 seconds.Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
sandbox/Dockerfile (1)
45-48: Optional: Verify downloaded binary integrity.Downloading executables without checksum verification is a supply chain risk. The jless releases include SHA256 checksums that could be validated.
🔐 Example with checksum verification (if version is pinned)
+ && JLESS_SHA256="<expected_sha256_here>" \ && curl -fsSL "$JLESS_URL" -o /tmp/jless.zip \ + && echo "${JLESS_SHA256} /tmp/jless.zip" | sha256sum -c - \ && unzip -o /tmp/jless.zip -d /usr/local/bin \🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sandbox/Dockerfile` around lines 45 - 48, Add checksum verification for the downloaded jless archive: when fetching $JLESS_URL into /tmp/jless.zip, also fetch or accept a pinned SHA256 value (e.g., JLESS_SHA256) or download the release .sha256 file and then run a sha256sum check against /tmp/jless.zip; if the checksum does not match, exit the build with a non-zero status and don’t install the binary. Update the Dockerfile steps that reference JLESS_URL and /tmp/jless.zip to perform the checksum fetch/compare before unzip, and ensure cleanup still removes /tmp/jless.zip on success or failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@sandbox/Dockerfile`:
- Around line 42-45: The Dockerfile extract assigns JLESS_URL and immediately
downloads it, but if the GitHub API/grep fails JLESS_URL will be empty and curl
will produce a confusing error; update the Dockerfile to validate JLESS_URL
after extraction (the JLESS_URL variable assignment and the subsequent curl -o
/tmp/jless.zip) and abort the build with a clear error message if it is empty or
invalid (for example check that JLESS_URL is non-empty and looks like an https
URL, then echo a descriptive error to stderr and exit 1), or alternatively parse
the API response more robustly (e.g., using jq) before calling curl.
- Around line 42-48: The Dockerfile step that discovers and installs jless via
the GitHub "releases/latest" API should be changed to pin to a concrete release
and to fail fast if the download URL is not found: replace the dynamic API
lookup that sets JLESS_URL with a hardcoded release URL (or a build ARG like
JLESS_VERSION used to construct
https://github.com/PaulJuliusMartinez/jless/releases/download/${JLESS_VERSION}/jless-<platform>.zip)
so builds are reproducible, and add a check after computing JLESS_URL (the same
variable in the diff) that aborts the build with a clear error if JLESS_URL is
empty or the curl to download /tmp/jless.zip fails before proceeding to
unzip/chmod/remove the archive.
---
Nitpick comments:
In `@sandbox/Dockerfile`:
- Around line 45-48: Add checksum verification for the downloaded jless archive:
when fetching $JLESS_URL into /tmp/jless.zip, also fetch or accept a pinned
SHA256 value (e.g., JLESS_SHA256) or download the release .sha256 file and then
run a sha256sum check against /tmp/jless.zip; if the checksum does not match,
exit the build with a non-zero status and don’t install the binary. Update the
Dockerfile steps that reference JLESS_URL and /tmp/jless.zip to perform the
checksum fetch/compare before unzip, and ensure cleanup still removes
/tmp/jless.zip on success or failure.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Addresses CodeRabbit review finding: if the GitHub API request or greppattern change silently, JLESS_URL would be empty and the subsequent curl would produce a confusing error. Validate it's non-empty and emit a descriptive message before attempting the download.
2 participants
Summary
Install
jless(a pager/viewer for JSON and JSONL) into the base sandbox Docker image. Fetches the latest release from the GitHub API dynamically so we're not pinned to a specific version.Why
The sandbox is increasingly used to inspect saved session transcripts (
.evolve/trajectories/*.jsonl) and API responses.jlessmakes browsing those files tractable without leaving the container —cat | lesson a multi-MB JSONL is painful.Test plan
just sandbox-build claudesucceedsjless --versionreturns a versionjless /workspace/.evolve/trajectories/claude-transcript_*.jsonlopens an interactive viewerSummary by CodeRabbit
jlesstool from GitHub releases.