[ptr727]

Summary

Agents kept reporting that a real-tool check could not run because the host's FFmpeg or HandBrake was older than the startup minimum. OPERATIONS.md now states the expectation and how to meet it:

• Local Verification: running PlexCleaner against real media tools needs none of them on the host. A missing or outdated host tool is never a reason to skip a real-tool check, and the check runs in the published image.
• Test an unreleased build in the image: the develop tag works in place of latest, as of its last dispatch from develop, since the weekly schedule refreshes only latest.
• Test a tool version the image does not carry (new runbook): mount a static FFmpeg (the existing paragraph, moved here), or build a local image from Docker/Dockerfile with the tool sourced from its own apt repository, a PPA, or a static build on PATH. The build uses --pull --no-cache and no --platform. getversioninfo confirms the versions the image carries.

Verification

• prose_lint.py --diff origin/develop, markdownlint, and CSpell are clean.
• The image paths and the getversioninfo output were checked by running ptr727/plexcleaner:develop. getversioninfo --settingsfile lists FfMpeg, FfProbe, MkvMerge, MkvPropEdit, MediaInfo, HandBrake, and SevenZip.
• Local strict review ran three passes (two edit rounds). The declined findings follow.

Declined Findings

• Consolidating the new Local Verification paragraph with "Tool Usage": Local Verification owns the verification rule, and Tool Usage describes what the image bundles.
• Consolidating the runbook's build command with the Docker/Dockerfile header comment: the comment is a developer note, and the runbook's command differs by design (--pull --no-cache, no --platform).

Pre-existing findings, not filed

• Docker/README.md:15 (pre-existing, wording): "Images are rebuilt weekly" holds for latest only, since the schedule rebuilds main, and develop refreshes on dispatch.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 17 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 21f8100d-0d24-4ef2-90e8-6c8d2ba7bef6

Commits

Reviewing files that changed from the base of the PR and between 423afab and 70d59bb.

Files selected for processing: 1

• OPERATIONS.md

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

• X
• Mastodon
• Reddit
• LinkedIn

[ptr727]

A recorded local strict-review pass covers head 70d59bb4c3eb49c54b6f8a5e3a9ef360aafe21d8, the content this pull request carries at that commit against develop, and it recorded 0 findings.

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Document container-based real-tool testing

📝 Documentation 🕐 Less than 10 minutes

AI Description

• Clarify that missing or outdated host media tools must not prevent real-tool verification.
• Explain when to use published latest or develop images for branch builds.
• Document container-based options for testing tool versions absent from published images.

Diagram

graph TD
  Change["Processing change"] --> Choice{"Tool in tag?"} -->|yes| Published["Published image"] --> Versions["Verify versions"] --> Media["Real-media check"]
  Choice -->|no, FFmpeg| Static["Static FFmpeg mount"] --> Versions
  Choice -->|no, other tool| Local["Local image build"] --> Versions

Loading

High-Level Assessment

Keep the verification rule and its runbooks in OPERATIONS.md: they address the reason checks were being skipped and provide paths for both published and unavailable tool versions. Host-tool testing was considered but cannot establish behavior in the shipped image.

Files changed (1) +19 / -0

Documentation (1) +19 / -0

OPERATIONS.mdRequire container-based real-tool checks and document tool-version options +19/-0

Require container-based real-tool checks and document tool-version options

• Clarifies that host media tools are unnecessary for real-tool verification and that older host tools do not establish shipped behavior. Explains the develop tag's publication cadence, moves the static FFmpeg guidance into a new runbook, and adds local-image build, test, and version-inspection instructions for tools absent from published tags.

OPERATIONS.md

[Copilot]

🟢 Approval recommended

The documented Docker-based verification guidance has no remaining active issues requiring resolution.

No open issues 🎉

What changed in this PR

Updates OPERATIONS.md to document Docker-based real-tool verification, ensuring host tool availability and versions do not prevent media-processing checks.

Changes:

• Clarifies that real-tool checks run inside the published Docker image.
• Documents using the develop image tag for unreleased builds.
• Adds instructions for building local images with alternate tool versions.
• Documents verifying bundled tool versions with getversioninfo.

This pull request is ready to be approved.

File	Description	Review Findings
OPERATIONS.md	Adds Docker-based real-tool verification guidance and local image build instructions.	2 nit findings: use title case for the new heading and clarify that the static build belongs in a directory on PATH.

_{Review effort: Lite}