[Feature Request] Support publishing review results to Gerrit Change

[lwintermelon]

Problem Statement

Gerrit is a well-know patchset based code review platform, its model fits ocr well.

Proposed Solution

Just like we add support for GitFlic

Alternatives Considered

No response

Affected Area

Other

Additional Context

No response

[stay-foolish-forever]

@lwintermelon Thanks for the suggestion! We agree that Gerrit's patchset-based model is a great fit for ocr.

That said, Gerrit differs from GitFlic in one important way that shapes how the integration should look:

• GitFlic ships a built-in CI/CD engine. It has its own pipeline runner, a gitflic-ci.yaml at the repo root, and Merge Request Pipelines that fire automatically on MR events. That's why we could ship the GitFlic integration as a self-contained example: one YAML + one Python glue script and you're done.

• Gerrit has no built-in CI. Its official documentation contains no pipeline chapter — Gerrit is purely a review server. Running anything on patchset-created requires an external CI system:

  • Gerrit server-side hooks
  • Zuul
  • Jenkins + Gerrit Trigger plugin — the Gerrit project itself uses this (gerrit-ci-scripts)

Because of this, we can't ship a single drop-in CI file the way we did for GitFlic. What we can (and plan to) provide is:

1. A publishing script that consumes ocr review --format json and posts to Gerrit's POST /a/changes/{id}/revisions/{rev}/review endpoint (inline comments in a single batched call — Gerrit doesn't need the old-side line mapping GitFlic does).
2. Example integrations for the common trigger paths above (Jenkins job / Zuul job / hook script), so users can plug the publisher into whichever CI platform they already run alongside Gerrit.

We're currently scoping the effort and the change surface, and expect to land support in the near future. Contributions and feedback on the preferred trigger path (Jenkins vs. Zuul vs. hooks) are very welcome — it would help us prioritize the example we ship first.

[lwintermelon]

@stay-foolish-forever [Edit]: Thanks for the feedback, you've made it very clear, I completely agree with you, 1. is a good start point, and AI code review itself is fundamentally independent of any CI system.

And Gerrit itself does provide an event system, it's also how Zuul and Jenkins CI works for Gerrit. Gerrit natively supports both SSH event streams¹ and webhooks².

So for Gerrit, a standalone script that utilizes Gerrit Events/REST API is more than enough and keeps it completely decoupled from any CI engine. There is no reason to treat Gerrit any differently. That said, I do admit that leveraging an existing CI system (like Zuul) or a dedicated Gerrit plugin would be easier upfront, as they handle checking out the source code to a specific workspace automatically.

Footnotes

1. Gerrit SSH cmd-stream-events ↩

2. Gerrit Webhooks Plugin Config ↩