Pass standard target packaging env vars to targets#33
Merged
Conversation
Targets now receive JAM_FUZZ, JAM_FUZZ_SPEC, JAM_FUZZ_DATA_PATH, and
JAM_FUZZ_SOCK_PATH on every startup per the jam-conformance fuzz-proto
spec, while the legacy {TARGET_SOCK} cmd-line substitution stays as a
fallback so existing targets keep working unchanged.
The data dir is wiped between sequential fuzz-source runs to match
official testing's fresh-init behavior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 Walkthrough🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Review rate limit: 3/5 reviews remaining, refill in 16 minutes and 55 seconds. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@tests/common.ts`:
- Around line 118-122: The shell command in tests/common.ts currently
interpolates volumeName directly into execSync command strings (see
createSharedVolume() and clearDataDir() where execSync(...) builds `... -v
${volumeName}:/shared ...`), which risks shell injection if volumeName contains
metacharacters; change these to invoke Docker without a single interpolated
shell string by using a child_process API that accepts an argv array (e.g.,
execFileSync or spawnSync) and pass volumeName as a separate argument (or
construct the -v argument as a single array element like
`${volumeName}:/shared`) instead of embedding it in a shell, and apply the same
fix to the other similar execSync usages noted in the file (lines around
175-184).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 36e0b3f8-c710-4fe4-b626-c4b98513d8c5
📒 Files selected for processing (3)
README.mdtests/common.tstests/fuzz-source/common.ts
- Add JAM_FUZZ_LOG_LEVEL=debug to the standard target env vars. - Switch docker invocations from shell-string execSync to argv-based execFileSync (via a small docker() helper) so volumeName interpolation isn't shell-parsed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
tomusdrw
added a commit
that referenced
this pull request
May 6, 2026
The graymatter target fails when started with the legacy fuzz-m1-target cmd-line args. It now reads JAM_FUZZ, JAM_FUZZ_SOCK_PATH, etc. from the standard target packaging env vars (added in #33), so we can launch it with no cmd args at all. - demo-source.yml: docker_cmd is now optional (default ""). - graymatter-fuzz.yml: drop docker_cmd entirely. - tests/common.ts: TARGET_CMD no longer required; buildCmdArgs("") already collapses to no args. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
Sets the standard target packaging env vars on every target container so teams that have migrated can rely on them, while keeping the existing
{TARGET_SOCK}cmd-line substitution as a fallback.JAM_FUZZ=1,JAM_FUZZ_SPEC=tiny,JAM_FUZZ_DATA_PATH=/shared/data,JAM_FUZZ_SOCK_PATH=/shared/jam_target.sockinto everystartTargetcall.TARGET_ENV/docker_envis appended last so teams can still override (docker-eis last-wins).createSharedVolumenow also creates/shared/data(777) so targets can write their cache there.clearDataDirwipes/shared/databetween sequential fuzz-source runs to match official testing's fresh-init behavior between sessions. First run starts on an already-fresh volume, so we only clear before runs 2..N.JAM_FUZZ_LOG_LEVELis intentionally not set by default — teams already set their own logging viadocker_env(e.g. typeberry usesJAM_LOG=log).Out of scope / not changed
--repeatsessions: the picofuzz binary drives those Initialize cycles internally, so the harness can't easily clear between them. The data dir is a startup cache per the spec, and per-session correctness is the target's responsibility onInitializereset.fuzzSource— graymatter is the source, not a target.Test plan
*-performanceworkflow on a representative target and confirm it still passes (legacy targets must keep working via{TARGET_SOCK}fallback).*-fuzzworkflow withnum_runs > 1and verify the data dir is cleared between runs (look for the alpinerm -rf /shared/datastep in logs).docker inspectof a running target shows the new env vars set.🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Tests