tree: 6a301220ff9826000753fa544e8d8bbf69b51209 [path history] [tgz]
  1. .settings/
  2. gr-verify-status/
  3. src/
  4. tools/
  5. .bazelignore
  6. .bazelrc
  7. .bazelversion
  8. .gitignore
  9. bazlets.bzl
  10. BUILD
  12. plugin.html

Gerrit Verify Status Plugin

A typical Gerrit installation contains integration with an automated testing system that evaluates patchsets and reports results to Gerrit. The only way for a Continous Integration system to report results to Gerrit is by posting a review as a comment. The problem with this workflow is that automated reviews and human reviews are stored as one piece of data (comments). Human reviews are inherently different than automated reviews. Human reviews have more meaning to other human reviewers, it serves as a conversation between people that are reviewing the change and thus it is typically given higher priority over automated reviews. Comments provide a great forum to discuss a change however when robots clutter that forum it overwhelms human reviewers and thus impedes the discussion. Robots should have a separate feedback channel so that the data can be easily queried, viewed and analyzed independently from human comments.

This is where the verify-status plugin may help. It creates a separate “verify-status” channel for automated systems to report test results. It provides a set of SSH commands and REST endpoints allowing easy integration with any CI system. It allows the verify-status data to be stored in the Gerrit database or on a completely separate database. It provides a set of UI components to view the data independent of Gerrit comments. Lastly there's even a Jenkins plugin (Gerrit verify status reporter) that will publish test results to gerrit using this new communications channel.

More information about this plugin can be found in the documentation. Additionally the Gerrit verify status reporter plugin provides a quick start guide that has a complete set of instructions on how to integrate Gerrit verify status with Jenkins.