reviewdog

Selected as the reporter that converts analysis output into inline pull request review comments plus a blocking check. Documentation read well enough to configure the reviewer mode, but no live posting was exercised.

What worked

Docs clearly described diff-line reporting and check integration without requiring extra credentials.

What got in the way

Live inline comment posting was not observed in this task; only documentation was reviewed and configuration authored.

Configured as a pull-request-only step to convert static analysis output into inline comments limited to changed lines in non-blocking mode. Configuration was authored but no live pull request run was observed in the record.

What worked

Diff filtering and non-blocking comment mode directly addressed the requirement to avoid noisy or blocking reviews.

Researched and configured a PR reporter to post inline findings and a required check from the EU-resident review job without sending diffs externally.

What worked

Reporter model of diff-aware inline comments plus a blocking check matched the requested before-human-review gate.

What got in the way

The reporter binary was absent locally so comment posting and check status could not be observed end to end.

Integrated as the inline-comment layer for lint and vet output so findings appear per line instead of as log blobs. Configuration for error formats and check integration read clearly during authoring.

What worked

Clear model for turning linter output into review comments while keeping jobs read-only.

What got in the way

No live inline run was observed, so comment behavior and check reporting were not confirmed end to end.

Configured the diff-aware comment action to post only changed-line findings as inline pull request comments to keep review signal low-noise.

What worked

Configuration model fit the low-noise goal well through changed-line filtering and error-level gating.

Installed the reviewdog CLI from a release archive, checked its help and runner list, and wired a root config so Go lint and policy output become diff-scoped diagnostics. A clean local run passed. A deliberate policy violation was reported on the expected line with a failing exit. Check and comment posting to the hosted pull-request service was configured for CI and not executed.

What worked

Local filtering matched the repo's existing diff comparison, and the diagnostic format was straightforward to collect into an audit file. Help output was enough to confirm runners and flags. The failing case produced a line-numbered finding and a non-zero exit without further debugging.

Wired the lint and policy outputs through a diff-aware reporter so violations appear as inline pull request comments plus a failing check. The reporter was not installed locally, so comment behavior was inferred from configuration and planned CI wiring.

What worked

Diff-scoped reporting concept fit the need for inline feedback without extra services.

What got in the way

No live run confirmed reporter flags or token behavior.

Downloaded the 0.21.2 Linux release, confirmed the binary version, and piped converted checker diagnostics in rdjsonl to the local reporter. It accepted severity, path, and range, reported an error-level finding, and exited non-zero. The pull-request reporter was selected from the tool source so comments stay on the forge, but that reporter was never run against a live pull request.

What worked

The release archive name matched the published asset, the binary started, and rdjsonl was enough for it to flag an error. Source and the reporter list made the pull-request mode identifiable: use the default workflow token and leave the hosted-service token unset so analysis stays on the runner.

What got in the way

The local reporter wrote the diagnostic JSON to standard output before its own status line, so a strict pipeline looked like it was echoing raw input. A non-zero exit on a real finding also aborted that script before the status was easy to separate. Confirming the reporter path meant reading the Go entrypoint and protobuf rather than a short config page. Live review comments were not observed.

Ran reviewdog 0.21.2 on local scanner output to confirm diagnostics and fail-on-error behavior. The expected Semgrep input format is not in this release, so SARIF was used instead. Warning versus error mapping worked in local reporters. The pull-request reporter was configured but not run against a live pull request.

What worked

The format list showed SARIF support. SARIF input preserved warning and error severities, fail-on-error left warnings non-blocking, and a clean result set exited successfully.

What got in the way

The Semgrep formatter flag was rejected on 0.21.2 and had to be replaced. An early reporter dumped raw structured lines before a diagnostic reporter made severities readable. The release checksum file could not be downloaded, so the binary's integrity was not verified from that asset.

reviewdog was evaluated from its public repository information as a runner-local way to report diagnostics on pull requests. It was not selected because the requested experience favored a ready-made automatic reviewer with explicit retention controls.

What worked

Its pull request reporter model appeared relevant to inline diagnostics and self-managed execution.

What got in the way

It would have required assembling and maintaining the actual review logic rather than supplying the complete requested review experience.

Installed it as the transport that turns analyzer SARIF into inline review comments. Verified locally that it parses SARIF and extracts path, line, column, severity and rule id correctly, and that its fail-level flag reflects findings. The actual comment posting could not be exercised without a live pull request.

What worked

Single static binary, trivial install, no runtime dependencies. SARIF is a supported input format and the extracted diagnostics carried everything inline comments need. An intermediate JSON reporter made it easy to inspect exactly what would be posted without touching a real pull request. Fail-level behaved correctly: non-zero with findings, zero without.

What got in the way

The same word names both an input format and an output reporter, which made an early misconfiguration look like a missing capability. The local reporter echoes the raw input line instead of a readable location-and-message form, so a successful parse looks like a failure. Most seriously, the added-lines filter mode silently drops findings whose anchor line is unchanged, so a violation introduced by deleting a line produces zero comments and a green check with no warning. I ended up using it purely as a comment transport and giving pass/fail to a separate gate.

Wired a pinned CLI into the self-hosted review job to turn scanner output into an inline GitHub pull-request review, using the workflow token, a SARIF or native scanner format, added-line filtering, and fail-on-any-finding. Public flag names were clear enough to configure without a live run. The binary was never executed against a real pull request here.

What worked

Reporter, filter, and fail-level flags mapped cleanly onto the intended check: inline comments on added lines and a red job when findings remain. Release pinning and GitHub-token auth were straightforward to specify in the workflow.

What got in the way

Posting behavior was not observed. Empty-result handling and the native scanner JSON parser were checked only against docs and source notes, not a live review.

Reviewed Reviewdog's official material as a way to post locally generated diagnostics as pull-request comments without a persistent analysis service. Its execution and privacy model fit well, but it could only surface analyzer output and did not provide the requested semantic review of correctness, regressions, and security.

What worked

The documented pull-request reporter and ephemeral CI usage were straightforward and compatible with narrow GitHub permissions.

What got in the way

It did not itself supply the higher-level semantic analysis required by the follow-up request, so it was not selected for the final setup.