IMPORTANT: On Gerrit 2.7+, you also need to grant "Stream Events" capability. Without this, the plugin will not work, will try to connect to Gerrit repeatedly, and will eventually cause OutOfMemoryError on Gerrit.

Then provide the name of the branch(es) to trigger on. The same "pattern types" is available as above. So for example to trigger on all branches in the project you can specify: Type: Path Pattern: ** You can add more branch patterns by clicking on "Add Branch" and more projects by clicking "Add Project".

The same syntax works for specifying which file(s) to trigger on (this is only available in version 2.3 or higher of Gerrit).

Dynamic triggering

From version 2.6.0 of the plugin, a new way of configuring what projects, branches and files to trigger on is available. By checking the checkbox "Dynamic Trigger Configuration", the user is asked for the URL to a file.

On a set interval, the plugin fetches and parses this file. The file contents should follow this syntax:

Usage with the Git Plugin

To get the Git Plugin to download your change; set Refspec to $GERRIT_REFSPEC and the Choosing strategy to Gerrit Trigger. This may be under ''Additional Behaviours/Strategy For Choosing What To Build' rather than directly visible as depicted in the screenshot. You may also need to set 'Branches to build' to $GERRIT_BRANCH. If this does not work for you set Refspec to refs/changes/*:refs/changes/* and 'Branches to build' to $GERRIT_REFSPEC.

Note: Be aware that $GERRIT_BRANCH and $GERRIT_REFSPEC are not set in the Ref Updated case. If you want to trigger a build, you can set Refspec and 'Branches to build' to $GERRIT_REFNAME.

Usage with Repo

If you are using a freestyle project and repo to download your code it would be as "easy" as.

Verifying functionality

Once you have restarted the connection, click on the Edit icon in the Server Table. If there is a problem with the Playback Manager's configuration, you will see this:

If the Playback Manager is correctly setup, you will see the following in the Jenkins log file when the Gerrit Server Connection is started:

INFO: (8) missed events to process for server: defaultServer ...

Skip Vote

"Skipping" the vote means that if more than one build is triggered by a Gerrit event the outcome of this build that "skips its vote" won't be counted when the final vote is sent to Gerrit. If this is the only build that is triggered then the vote will be 0.

This can be useful if you have one job that triggers on all patch set created events that just checks that the commit message is correctly formatted, so it should only deny merging if it is a bad commit message but also not allow the merge just because the message was ok. In that scenario you could configure the "check commit message" job to skip voting on Successful.

Additional Screenshots

Pipeline Jobs

Version 2.15.0 of the Gerrit Trigger plugin supports Jenkins Pipeline job types. So as with the traditional job types, this plugin supports:

Triggering of Pipeline Jobs based on Gerrit Event notifications e.g. the Patchset Created event.

Checkout of the change-set revision from the Gerrit Git repository. See example below.

The plugin doesn't currently offer a dedicated DSL syntax for performing the change-set checkout. However, it's very easy to perform the checkout using the Gerrit parameters provided to the build, along with the existing Workflow step for Git (or other supported SCM) e.g.

Note though that with this approach the changelog will not show correctly.

Tips & Tricks

This section contains some useful tips and tricks that users has come up with. Feel free to add your own.

Using "Build Now"

Normally when you have configured a job to be triggered by Gerrit you can't use the "Build Now" link anymore since your builds are dependent on information from Gerrit, especially if you are using the Git plugin to checkout your code in the workspace.

You can get around this limitation if you for example want to use the same job to build the master branch at some point. If you are using the Git plugin do the following

Add a String parameter called GERRIT_REFSPEC with the default value refs/heads/master

Using this trick will enable you to build, but no results will be sent to Gerrit since it is not triggered by it.

Multiple jobs review the same changeset (possibly giving different answers)

Note to Gerrit > 2.6 Users

The verdict category key values has changed in 2.6 from CDRV, VRIF to Code-Review and Verified. So in order to be able to trigger on comment added you need to change the settings on the "Manage Jenkins/Gerrit Trigger" page (it's hidden behind the advanced button) and reconfigure all your jobs so they can pick up the new values.

Alternately, you can remove the verified flag from the command used to submit votes for changes, and simply have the trigger submit code review votes:

Go to "Manage Jenkins" and click the "Gerrit Trigger" link

Under "Gerrit Servers" next to your server(s) click the "Edit" button (looks like a gear, other icons may overlap it)

Under "Gerrit Reporting Values" click the Advanced button at the bottom

Under "Gerrit Verified Commands" remove the '--verified <VERIFIED>' sections from each command, see screenshot

As of version 2.17.0 the verified "vote" is not sent at all to Gerrit (removed from the command line/rest call) unless there is an actual value to be sent. So if you change the configuration to contain only values for code review and empty strings for verified you won't get the error.

Change Log

Version 2.27.4 (released Feb 20 2018)

Bumped Gerrit Events library to 2.12.0 to fix a json-lib version conflict with Jenkins core

Version 2.23.0 (released Nov 25 2016)

Diagnostics pages: Management pages to get some diagnostics views into the internals of the trigger. Usable to troubleshoot why some strange behaviours are happening, with Support Core Plugin reports. (pull #275)

Version 2.18.1 (released Dec 3 2015)

Version 2.18.0 (released Dec 1 2015)

Changed the way "compound name and email" and GERRIT_CHANGE_COMMIT_MESSAGE (a.k.a "Readable message") parameters are configured. Users can now select between three modes: "Human readable", Encoded and "Do not add". With the same defaults as the old checkboxes. (pull #258)

Added the same mode configuration for the GERRIT_CHANGE_SUBJECT parameter. (pull #265)

Version 2.17.2 (released Oct 29 2015)

Version 2.17.1 (released Oct 28 2015)

Version 2.17.0 (released Oct 26 2015)

Update for upcoming change to Gerrit stream events in regards to updated attribute in Approval for responding to Comment Added events (pull #253)

JENKINS-30367,JENKINS-30393 Allow override of code-review/verified value from job (pull #255)This change also makes it so Jenkins doesn't send--verifiedat all for the review ssh command, if there is no value calculated, so if you change the defaults you shouldn't need to add the Verified label in Gerrit.