This plugin integrates Jenkins to Gerrit code review for triggering builds when a "patch set" is created.
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.
Specify the Gerrit server settings via "Manage Jenkins > Gerrit Trigger"
Fill in the server settings:
Click "Test Connection" to verify the connection.
When everything seems ok, save your settings and restart the connection in the "Control" section at the bottom of the page:
There are many more settings for your pleasure, look at the individual help sections for information what they are about.
In the "Build Triggers" section of your Job configuration page; tick "Gerrit event":
Specify what type of event(s) to trigger on:
If you don't specify any event; Patchset Created and Draft Published (if available) will be selected by default.
Specify what Gerrit project(s) to trigger a build on.
At least one project and branch pattern needs to be specified for a build to be triggered,and you can specify as many gerrit project to trigger on as you want.
Start by specifying the name of the Gerrit project in the left hand text field.
Then provide the name of the branch(es) to trigger on. The same "pattern types" is available as above.
The same syntax works for specifying which file(s) to trigger on (this is only available in version 2.3 or higher of Gerrit).
From version 2.6.0 of the plugin, a new way of configuring what projects, branches and files to trigger on is available.
On a set interval, the plugin fetches and parses this file. The file contents should follow this syntax:
p for project
Branch and file lines are assumed to be part of the closest preceding project line.
The dynamic triggering can be used in combination with the usual configuration, described above. The gerrit trigger will
trigger both for the dynamic and non-dynamic configurations.
The interval on which Jenkins fetches the file is configurable in the administrative pages for the Gerrit trigger, under advanced:
The reason for this functionality is that a user would want to update a list of what to trigger on outside of Jenkins.
Another use case is to run a build in Jenkins periodically that creates the list, then have several projects use the same list.
Gerrit doesn't use the standard repository hooks. To do an automatic update of jenkins on a patch you'll need to add a hook to the top-level gerrit hook directory ($site_path/hooks).
The equivalent of a git 'post-receive' hook for gerrit is a 'patchset-created' handler. More info on gerrit hooks can be found here:
To get the Git Plugin to download your change; set Refspec to $GERRIT_REFSPEC and the Choosing strategy to Gerrit Trigger. 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.
If you are using a freestyle project and repo to download your code it would be as "easy" as.
"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.
This section contains some useful tips and tricks that users has come up with. Feel free to add your own.
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
Using this trick will enable you to build, but no results will be sent to Gerrit since it is not triggered by it.
That's possible, see http://strongspace.com/rtyler/public/gerrit-jenkins-notes.pdf
Since the trigger adds a comment in Gerrit for each build start and end, usually all the reviewers get a notification email. This can get quite annoying. However, it's possible to configure Gerrit so that only the change owner and people who starred the change get a notification email. To do this DENY the 'Email Reviewers' capability for the Gerrit user that is used by Jenkins. See https://gerrit-review.googlesource.com/Documentation/access-control.html#capability_emailReviewers.
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.
Also note that the Verified flag is no longer in Gerrit by default, see http://gerrit-documentation.googlecode.com/svn/Documentation/2.6/cmd-review.html so you'll need to add it to Gerrit for new installs.
The search page will also not show the verdict of the patches until we've fixed that page, but it shouldn't hinder the functionality of that page.
2.13.0-beta-6 promoted to stable.
I Botched the beta-1 release.
Final rc for 2.12
Still calling it beta since I haven't had time o test it in a staging environment yet.
Bumped core dependency to 1.509.3
2.11.0-beta-4 promoted to "stable".
Last release for the year.
This version contains a lot of refactoring under the hood to make some of the features and future work possible.
This is built against Jenkins 1.400 to have an easier release process, but it should still be binary compatible with Hudson 1.362+
Skip to end of metadata Go to start of metadata