Add graymatter fuzz source for turbojam (1M blocks)

[tomusdrw]

Summary

• Add proper long-running graymatter fuzz source job for turbojam: 10 runs x 100k blocks = 1M total blocks
• Add daily schedule (18:00 UTC) matching other implementations
• Keep existing demo fuzz job unchanged

Notes

• Requires a self-hosted runner with the turbojam label for the graymatter-source job
• Timeout set to 60 minutes

Test plan

• Verify the graymatter-source job runs successfully via workflow_dispatch
• Confirm the demo job still works as before

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • CI workflows now run on a daily schedule (18:00 UTC) and explicitly grant read access to repository contents and write access to issues.
  • Reusable job invocations were standardized to pass target-specific runtime parameters (target name, container image, command, memory/env, readiness hints, and mention) across multiple workflows.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 80603631-6a03-4a52-bee8-39e8c27fde20

📥 Commits

Reviewing files that changed from the base of the PR and between 76bd205 and 69d2226.

📒 Files selected for processing (1)

• .github/workflows/turbojam-fuzz.yml

---

📝 Walkthrough

Walkthrough

Added top-level workflow permissions and standardized reusable-workflow inputs across many fuzzing workflows; turbojam also gains a daily cron trigger and a new graymatter-source job invoking the graymatter-fuzz-source reusable workflow with Turbojam-specific parameters. (50 words)

Changes

Cohort / File(s)	Summary
Turbojam (schedule + new job) .github/workflows/turbojam-fuzz.yml	Added daily cron trigger and a new graymatter-source job that invokes graymatter-fuzz-source with Turbojam-specific inputs (target_name, docker_image, docker_cmd, timeout_minutes, num_blocks, num_runs, mention).
Workflows adding permissions + with inputs .github/workflows/boka-fuzz.yml, .github/workflows/graymatter-fuzz.yml, .github/workflows/jamforge-fuzz.yml, .github/workflows/jampy-fuzz.yml, .github/workflows/jampy-recompiler-fuzz.yml, .github/workflows/jamzilla-fuzz.yml, .github/workflows/jotl-fuzz.yml, .github/workflows/new-jamneration-fuzz.yml, .github/workflows/pyjamaz-fuzz.yml, .github/workflows/turbojam-fuzz.yml	Added top-level permissions: contents: read and issues: write; extended demo/reusable-workflow invocations with with inputs such as target_name, docker_image, docker_cmd, and optional docker_memory, docker_env, readiness_pattern, or mention.
Workflows adding only permissions .github/workflows/jam4s-fuzz.yml, .github/workflows/jamzilla-int-fuzz.yml, .github/workflows/javajam-fuzz.yml, .github/workflows/pbnjam-fuzz.yml, .github/workflows/typeberry-fuzz.yml	Added top-level permissions: contents: read and issues: write without changing job inputs or control flow.

Sequence Diagram(s)

sequenceDiagram
  participant Scheduler as Scheduler (cron)
  participant GH as GitHub Actions
  participant Reusable as graymatter-fuzz-source (reusable workflow)
  participant Runner as Actions Runner
  participant Docker as Docker container / Fuzzer

  Scheduler->>GH: trigger turbojam-fuzz (daily)
  GH->>Reusable: invoke graymatter-fuzz-source (with turbojam inputs)
  GH->>Runner: schedule job
  Runner->>Docker: start image (docker_image) and run docker_cmd
  Docker->>Reusable: run fuzzer against {TARGET_SOCK}
  Docker-->>Runner: report results / exit
  Runner-->>GH: upload logs / create issue (if configured)

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Add jampy recompiler #16 — Modifies jampy-recompiler-fuzz.yml with the same reusable-workflow invocation and matching inputs (target_name jampy-recompiler, docker_image, docker_cmd, mention).
• Add graymatter fuzz source workflow #9 — Introduced the graymatter-fuzz-source reusable workflow that the turbojam change now invokes on a schedule.
• Add jampy target to workflows #6 — Updated jampy-target workflow invocations with identical target_name, docker_image, and docker_cmd inputs, similar to changes here.

Poem

🐰 I hopped through YAML lines with glee,

Scheduled runs and targets set free,
Inputs snug in each little fence,
Fuzzers dance — precise and dense,
Cheers from a rabbit, small and nifty! 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the primary change—adding a graymatter fuzz source for turbojam with 1M blocks—which is the main focus of the PR objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch turbojam-fuzz-1m

📝 Coding Plan

• Generate coding plan for human review comments

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/turbojam-fuzz.yml (1)

12-21: Consider pinning the Docker image to a specific version for reproducibility in fuzz testing.

Using :latest (line 16) means the image can change between runs without any workflow modification, potentially affecting the consistency of fuzz test results. For fuzzing workflows, reproducibility is important to meaningfully compare runs and track regressions.

The reusable workflow correctly configures the self-hosted runner with runs-on: [self-hosted, "${{ inputs.target_name }}"], which resolves to [self-hosted, "turbojam"] as intended.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/turbojam-fuzz.yml around lines 12 - 21, The Docker image
for the graymatter-source step is currently pinned to
'r2rationality/turbojam-fuzz:latest' which harms reproducibility; update the
docker_image input (the docker_image key in the graymatter-source block) to a
specific version tag or, better, an immutable digest (e.g.
r2rationality/turbojam-fuzz:vX.Y.Z or r2rationality/turbojam-fuzz@sha256:...) so
runs of the reusable workflow with target_name and docker_cmd remain
deterministic and comparable across fuzz test runs; ensure the updated value
replaces the current 'latest' string used by the graymatter-source block.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/turbojam-fuzz.yml:
- Around line 12-21: The Docker image for the graymatter-source step is
currently pinned to 'r2rationality/turbojam-fuzz:latest' which harms
reproducibility; update the docker_image input (the docker_image key in the
graymatter-source block) to a specific version tag or, better, an immutable
digest (e.g. r2rationality/turbojam-fuzz:vX.Y.Z or
r2rationality/turbojam-fuzz@sha256:...) so runs of the reusable workflow with
target_name and docker_cmd remain deterministic and comparable across fuzz test
runs; ensure the updated value replaces the current 'latest' string used by the
graymatter-source block.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a9e40f77-3837-4191-8365-6e51c1cb6f14

📥 Commits

Reviewing files that changed from the base of the PR and between a58e8d3 and 11c9f17.

📒 Files selected for processing (1)

• .github/workflows/turbojam-fuzz.yml