Skip to end of metadata
Go to start of metadata
This plugin integrates Jenkins to Gerrit code review for triggering builds when a "patch set" is created.

Plugin Information

View Gerrit Trigger on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

Set Up

Gerrit access rights

  1. Create the profile through in Gerrit web interface for your Jenkins user, and set up a SSH key for that user.
  2. Gerrit web interface > Admin > Groups > Non-Interactive Users > Add your jenkins user.
  3. Admin > Projects > ... > Access > Edit
    • Reference: refs/*
      • Read: ALLOW for Non-Interactive Users
    • Reference: refs/heads/*
      • Label Code-Review: -1, +1 for Non-Interactive Users
      • Label Verified: -1, +1 for Non-Interactive Users

Gerrit documentation: http://gerrit-documentation.googlecode.com/svn/Documentation/2.4.2/access-control.html#examples_cisystem

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.

  1. Gerrit web interface > People > Create New Group : "Event Streaming Users". Add your jenkins user.
  2. Admin > Projects > All-Projects > Access > Edit
    • Global Capabilities
      • Stream Events: ALLOW for Event Streaming Users

https://gerrit-documentation.googlecode.com/svn/Documentation/2.7/access-control.html#capability_streamEvents

Administrative Settings

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.

Trigger Configuration

In the "Build Triggers" section of your Job configuration page; tick "Gerrit event":

Specify what type of event(s) to trigger on:

  • Draft Published: Sent when a change moves from draft state to new. (only available in version 2.5 or higher of Gerrit).
  • Patchset Created: Sent when a new patchset arrives on a change. Before version 2.6.0, this was the only event you could trigger on.
  • Change Merged: Sent when a change is merged on the Gerrit server.
  • Comment Added: Sent when a comment is added to a change. Which category and value to trigger on can be configured. The available categories can be configured in the server settings for the plugin.
  • Ref Updated: Sent when a ref is updated on the Gerrit server, i.e. someone pushes past code review.

If you don't specify any event; Patchset Created and Draft Published (if available) will be selected by default.


Comment added configuration.

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.
You can specify the name pattern in three different ways, as provided by the "Type" drop-down menu.

  • Plain: The exact name in Gerrit, case sensitive equality.

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:

p=some/project
b^**/master/*
f~.*\.txt
p=some/other/project
b^**

Explanation:

p for project
b for branch
f for file
= for plain syntax
^ for ANT style syntax
~ for regexp syntax

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:

Note1: anonymous user must have READ permissions to Jobs in order for this feature to work.

Note2: a specific Gerrit server must be selected selecting "any server" will not trigger jobs.

Use case

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 hooks

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:

http://gerrit.googlecode.com/svn/documentation/2.1.2/config-hooks.html

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.

repo init -u git://gerrit.mycompany.net/mymanifest.git
repo sync
repo download $GERRIT_PROJECT $GERRIT_CHANGE_NUMBER/$GERRIT_PATCHSET_NUMBER

Missed Events Playback Feature (Available from v. 2.14.0)

Note

This feature replaces the "Check Non-Reviewed Patchsets" option that was part of a Job's Gerrit Trigger configuration.

If your Jenkins instance has been down for a period of time (upgrade or maintenance), the Missed Events Playback Feature ensures that any missed events are re-played and builds are triggered.

The mechanics are as follows:

  • The Playback Manager maintains a last known alive timestamp of events that were received by the Gerrit Server connection.
  • Upon re-connect, a request is made to the Gerrit Events-Log plugin installed on the Gerrit Server to determine which events may have been missed while the connection was down.
  • The events are then added to the Gerrit Trigger event queue to be processed.

Setup Requirements

The Playback Manager requires:

Setting up the REST api
  • To setup the REST api for the Gerrit Server Connection, navigate to Manage Jenkins > Gerrit Trigger and click on the Edit icon for the Server Connection.
  • Click on Advanced, and enter the Gerrit HTTP User and Gerrit HTTP Password values as shown below.

  • Click on Test REST Connection to verify the user and password settings.
  • Click on Save
  • Restart the connection using the Status icon in the Server Table shown below:

Gerrit Server Events-Log plugin

Gerrit Server Events-Log plugin

Please note that if the Gerrit Server Events-Log plugin is not installed on the Gerrit Server, then the Playback Manager will be disabled.

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:

  1. Triggering of Pipeline Jobs based on Gerrit Event notifications e.g. the Patchset Created event.
  2. Checkout of the change-set revision from the Gerrit Git repository. See example below.
  3. Sending of the "build completed" command to Gerrit (with Verified label etc).

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.

node {
  // Checkout the Gerrit git repository using the existing
  // workflow git step...
  git url: '<gerrit-git-repo-url>'

  // Fetch the changeset to a local branch using the build parameters provided to the
  // build by the Gerrit plugin...
  def changeBranch = "change-${GERRIT_CHANGE_NUMBER}-${GERRIT_PATCHSET_NUMBER}"
  sh "git fetch origin ${GERRIT_REFSPEC}:${changeBranch}"
  sh "git checkout ${changeBranch}"

  // Build the changeset rev source etc...
}

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)

That's possible, see http://strongspace.com/rtyler/public/gerrit-jenkins-notes.pdf

Reduce number of notification emails

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.

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.

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.  This can easily be added back to all projects.  Otherwise the Gerrit Trigger will fail to submit votes for jobs, due to the invalid label.

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:

  1. Go to "Manage Jenkins" and click the "Gerrit Trigger" link
  2. Under "Gerrit Servers" next to your server(s) click the "Edit" button (looks like a gear, other icons may overlap it)
  3. Under "Gerrit Reporting Values" click the Advanced button at the bottom
  4. 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.7 (released Sep 3 2018)

  • Assure the connection get closed after check. (#375)
  • Upgrade animal-maven-sniffer-plugin to 1.17 (#377)
  • Diagnostics: Remove redundant 'unused' suppressions (#376)

Version 2.27.6 (released Aug 24 2018)

  • Fix typo in javadoc (#371)
  • Null check getConfigXml() (#369)
  • Also specifiy a tag when using the SSH API (#368)
  • Add autogenerated prefix to the jenkins-gerrit-trigger tag (#366)
  • Fix race condtion in ssh key generation (#362)
  • Remove jobs from all memory entities (#352)
  • JENKINS-49813 - RunningJobs: Remove extra shouldCancelPatchsetNumber check (#356)
  • Clean runningJob class from stupid mistakes (#357)
  • Add proxy to avoid too much connections (#353)

Version 2.27.5 (released Feb 26 2018)

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
  • Optimized event processing a bit (#355)
  • JENKINS-39498 - Getting issue details... STATUS  Stop panicking about "eventCreatedOn" and losing my position (#346)
  • JENKINS-48622 - Getting issue details... STATUS  Reduced logging spam from GerritMissedEventsPlaybackEnabledChecker (#349)

Version 2.27.3 (released Jan 26 2018)

  • Fixed some NullPointerExceptions and other code fixes (#342, #344, #345)
  • Fixed a race condition (#340)
  • UI Fixes and tweaks (#341, #347)
  • JENKINS-49163 Create correct url in Diagnotic Event Listeners report for jobs located in folders (#348)

Version 2.27.2 (released Jan 15 2018)

Version 2.27.1 (released Dec 06 2017)

Version 2.27.0 (released Dec 01 2017)

  • Provide the data about parent builds as environment variable to the dependent build (pull #319)
  • Fixed a race condition with dynamic config refresh interval (pull #334)
  • Fix the deadlock in RunningJobs (pull #333)

Version 2.26.2 (released Oct 30 2017)

  • Expand parameters in build messages (pull #331)
  • Reduced item lookup calls to save memory and performance (pull #332)

Version 2.26.1 (released Oct 12 2017)

Version 2.26.0 (released Sep 13 2017)

  • Added support for Topic Changed event (pull #324)

  • Fixed a deadlock in DependencyQueueTaskDispatcher (pull #325)

Version 2.25.0 (released Aug 11 2017)

Version 2.24.0 (released Jul 3 2017)

Version 2.23.3 (released Jun 9 2017)

Version 2.23.2 (released Apr 19 2017)

  • Update Gerrit documentation links to latest major release (pull #311)
  • Fix CommentAdded event for Gerrit snapshot version < 2.13 (pull #310)

Version 2.23.1 (released Apr 11 2017)

  • JENKINS-40059 - CommentAdded trigger firing on every comment (pull #302, pull #309)
  • Display full commit message in tooltip (pull #306)
  • Change Nr. is a link to review detail (pull #305)
  • Prevent double HTML escaping of subject in search results (pull #304)
  • #59 Bumped Gerrit Events to version 2.10.1 to fix an buffer issue for incoming JSON.

Version 2.23.0 (released Nov 25 2016)

  • JENKINS-38675 Use refspec instead of branch name for the revision (pull #299)
  • 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)
  • JENKINS-38974 fill in commentTextParameterMode if it's missing (pull #301)

Version 2.22.0 (released Aug 17 2016)

This version does not contain the changes in 2.22.0-beta-1, they will be incorporated at a later date

  • Prepare for git client plugin 2.0.0 coexistence with 1.x (pull #296)_
  • Operator '^' for dynamic trigger must be escaped in regex (pull #294)
  • JENKINS-30821 - Add comment-added comment as job parameter (pull #295)

Version 2.22.0-beta-1 (released Jul 06 2016)

Version 2.21.1 (released Jun 07 2016)

  • JENKINS-35364 Fixed a ClassNotFound due to the use of wrong StringUtils (pull #286)
  • JENKINS-35389 Fixed Jenkins getting wrong certificate if Gerrit is running with nginx reverse proxy and nginx configured to run multiple https sites. (pull #287)

Version 2.21.0 (released May 30 2016)

Version 2.20.0 (released Apr 12 2016)

  • Added Structs plugin Symbol annotations for concise DSL syntax (pull #280)
  • Fixed the "updated" check on Comment-added events introduced in 2.17.0 to look at the correct "oldValue" property instead (pull #279)

Version 2.19.0 (released Mar 31 2016)

Version 2.18.4 (released Mar 09 2016)

  • JENKINS-30857 Fixed Java 1.6 compatibility issue due to introduction of ReflectiveOperationException. (pull #276)
  • Also added animal sniffer to the plugin's build test phase to try to avoid the above problem in the future. (But you shouldn't be running Java 1.6 anyway, we will soon move away from it...)

Version 2.18.3 (released Jan 05 2016)

Version 2.18.2 (released Dec 11 2015)

  • Renamed review category deprecated default names CRVW and VRIF for new server configs (should have been done 2 years ago). (pull #270)
  • JENKINS-31894 Fixed problem where approvals were not displayed in Query and Trigger search results. (pull #272)

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.5 (released Nov 30 2015)

Version 2.17.4 (released Nov 27 2015)

Version 2.17.3 (released Nov 26 2015)

Version 2.17.2 (released Oct 29 2015)

  • Fix NPE involving null server CR/Ver labels (pull #257)

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 --verified at 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.

Version 2.16.0 (released Oct 02 2015)

Version 2.15.2 (released Sept 30 2015)

  • Fix to permit use of Forbidden files without File Paths (pull #251)

Version 2.15.1 (released Sept 14 2015)

Version 2.15.0 (released Aug 31 2015)

2.15.0-beta-1 promoted to stable

Version 2.15.0-beta-1 (released Aug 17 2015)

Version 2.14.0 (released Jun 05 2015)

2.14.0-beta-3 promoted to stable

Version 2.14.0-beta-3 (released May 27 2015)

Version 2.14.0-beta-2 (released May 26 2015)

  • Correct default values for Build Current Patchsets (pull #236)

Version 2.14.0-beta-1 (released May 20 2015)

Version 2.13.0 (released Apr 24 2015)

2.13.0-beta-6 promoted to stable.

Version 2.13.0-beta-6 (released Apr 7 2015)

Version 2.13.0-beta-5 (released Feb 23 2015)

  • Another regression from JENKINS-23152. The correct event handling methods wasn't called for some event types causing weird loop-triggering behavior. (pull #204)

Version 2.13.0-beta-4 (released Feb 16 2015)

Version 2.13.0-beta-3 (released Feb 6 2015)

  • Enabled Base64EncodedString parameter to be used with Rebuild plugin (pull #199)
  • Regression from JENKINS-23152 fix; Running event threads as SYSTEM user (pull #200)

Version 2.13.0-beta-2 (released Jan 15 2015)

I Botched the beta-1 release.

Version 2.12.0 (released Nov 14 2014)

  • 2.12.0-beta-5 promoted to stable
  • Added Japanese translations (pull #190)

Version 2.12.0-beta-5 (released Oct 30 2014)

Final rc for 2.12

Version 2.12.0-beta-4 (released Aug 28 2014)

  • Fixed disabled features not showing (pull #164)
  • JENKINS-24012 Fixed an issue with RabbitMQ (pull #166)
  • Added No connection on startup (pull #168)
  • Added selection for what labels to use for the REST API (pull #169)
  • Default "status:open" filled in on the search page (pull #163)
  • Added a trigger for comment added containing a specified RegEx (pull #170)

Version 2.12.0-beta-3 (released Jun 30 2014)

Still calling it beta since I haven't had time o test it in a staging environment yet.

Features and Fixes
  • Added option to exclude drafts when triggering on patchset created event (pull #153)
  • Permit the setting of Build Schedule Delay to "0". Delay not needed with Replication Events (pull #143)
  • Bug: Copy REST API settings when creating new server (pull #156)
  • Bug: Password for SSH authentication file is now encrypted (pull #157)
  • JENKINS-23165 Don't send plain text password to browser (pull #158)
  • JENKINS-23421 Add custom parameter type for Base64 encoded value (pull #160)
  • Filter on change-kind in patchset-created REWORK, TRIVIAL_REBASE, NO_CODE_CHANGE (pull #159)
  • Removed delayed approval feature JENKINS-11409 (commit 48311)

Version 2.12.0-beta-2 (released Apr 28 2014)

Features and Fixes

Version 2.12.0-beta-1 (released Apr 28 2014)

Bumped core dependency to 1.509.3

Features and Fixes
  • Code refactoring to "break out" the gerrit-events module into its own separate project.
  • Added a "Forbidden Files" optional parameter to Gerrit Projects (commit 43372)
  • JENKINS-11409 Delayed approval mechanism (commit 5f672)
  • Add Pseudo Mode to server configuration (commit 0e735)
  • NPE Fix in the connection watchdog
  • Fixed log annotator when "Any Server" was used. (commit f8e50)
  • Moved "Server Control Panel" to main Management page
  • Feature to block build until Gerrit replication is completed. (commit ab429)
  • JENKINS-21547 Add information to console log
  • New functionality allowing one project's trigger to depend on others'. (commit 08fb5)
  • Various doc and help fixes
  • Add option for selecting non-encoded string for multiline text parameters. (commit cb285)

Version 2.11.1 (released Mar 21 2014)

Version 2.11.0 (released Jan 14 2014)

2.11.0-beta-4 promoted to "stable".

Version 2.11.0-beta-4 (released Dec 18 2013)

Last release for the year.

Fixes
  • JENKINS-21067 New server config not reachable if using a prefix in URL

Version 2.11.0-beta-3 (released Dec 16 2013)

Fixes
  • One more "Any Server" fix.
  • small jelly fix to make the trigger work like before with the templates plugin.

Version 2.11.0-beta-2 (released Dec 9 2013)

Fixes
  • URL encoding for project and branch when calling the REST Api
  • Updated the Gerrit documentation link on the query page to point to 2.8
  • Various fixes for using the "Any Server" trigger option.

Version 2.11.0-beta-2 (released Dec 9 2013)

Fixes
  • URL encoding for project and branch when calling the REST Api
  • Updated the Gerrit documentation link on the query page to point to 2.8
  • Various fixes for using the "Any Server" trigger option.

Version 2.11.0-beta-1 (released Nov 26 2013)

This version contains a lot of refactoring under the hood to make some of the features and future work possible.

Features
  • [JENKINS-17850] Multiple Gerrit server support
  • Option to use REST Api for submitting review
    • Allowing other plugins to provide line comments via extension point
  • Option to check changes from Gerrit and trigger missed patchsets.
  • The change's full commit message is available in triggered jobs, if Gerrit provides it.
  • New build parameter: GERRIT_TOPIC.
Fixes
  • Replaced deprecated `gerrit approve` with `gerrit review` as default command.
  • [JENKINS-10709] Multiple builds are triggered for one change in Gerrit.
  • Fixed an NPE in Watchdog causing the days not to show in the config UI
  • Git choosing strategy no longer uses FETCH_HEAD but the actual revision instead
  • [JENKINS-20098] When computing the changelog in the Git Plugin using GerritTriggerBuildChooser an UnsupportedOperationException is thrown

Version 2.10.1 (released June 17, 2013)

Fixes
  • Fixed NPE on "Query and Trigger Gerrit Patches". 
  • Connection to Gerrit is delayed during startup until all jobs are loaded.

Version 2.10.0 (released May 30, 2013)

Features and Fixes
  • Added Retrigger permission. 
    • Anyone with Build permission will also have Retrigger so you won't need to change the authorization config.
    • Gives you the ability to deny people to build a job but retrigger it if for example some environment issue broke the build.
  • Japanese translations for the things added in 2.9.0

Version 2.9.0 (released Mar 12, 2013)

Features and Fixes
  • Added a watchdog that can restart the Gerrit connection if nothing has happened for x minutes
  • Fixed so that a reconnect is attempted if connection gets broken before stream-events is fully initiated.
  • SOCS5 and HTTP proxy support for connecting to Gerrit
  • Added new parameters: 
    • GERRIT_EVENT_TYPE - states what type of event that triggered the build
    • GERRIT_CHANGE_ABANDONER_NAME, GERRIT_CHANGE_ABANDONER_EMAIL
    • GERRIT_CHANGE_RESTORER_NAME, GERRIT_CHANGE_RESTORER_EMAIL

Version 2.8.0 (released Feb 21, 2013)

Features and Fixes
  • Trigger on change-abandoned and change-restored events.
  • Configuration to turn off the compound email parameter - workaround for parameter issues on Windows.
  • URLConnection to the dynamic trigger config should now be properly closed.
  • Removed use of deprecated APIs in git-plugin's BuildChooser; follow up fix to JENKINS-16851, new dependency to git-plugin 1.2.0.

Version 2.7.0 (released Dec 5, 2012)

Features and Fixes
  • Custom messages from plugins takes into account all builds for an event
  • Custom messages from plugins moved from CUSTOM_MESSAGE into BUILD_STATS variable, added a checkbox to turn on/off plugin messages.
  • Ability to "skip voting" for a specific build result.
  • Fixed a circularity bug in Comment Added event, so Jenkins won't trigger on comments from itself.
  • Upgraded jsch to 0.1.49
  • Build current patchsets only is no longer experimental
  • More Japanese translations
  • Fixes and additions to help files
  • Added a timeout when fetching dynamic configuration files
  • Bumped Jenkins core dependency to 1.424
Dev related
  • GerritCause is now a sub class of SCMTriggerCause
  • Done some cleanups in the gerrit-event module
  • checkstyle:check is executed in the maven test phase, so the build will fail if you have checkstyle warnings.
  • ToGerritRunListener now has an ordinal of 10 003

Version 2.6.0 (released Sep 19, 2012)

Features and Fixes
  • Dynamic Gerrit triggering.
  • Triggering on comment-added, change-merged, ref-updated and draft-published now possible.
  • Refactorization of GerritTriggeredEvents and hashCode method implementation for events.
  • Fixed a double-triggering when a project is renamed.
  • New extension point for plugins to add custom messages to Gerrit at beginning/end of build.
  • JENKINS-11726
  • JENKINS-11582
  • JENKINS-10055

Version 2.5.2 (released May 7, 2012)

Features and Fixes
  • Corrected Gerrit version requirements for the "trigger on files" feature, it is now set to 2.3.
  • No quiet period when triggering builds manually (Retrigger and "Query and Trigger Gerrit Patches")
  • Fixed a deadlock when a job is saved at the same time as its being triggered.
  • More Japanese translations.

Version 2.5.1 (released Mar 13, 2012)

Features and Fixes
  • JENKINS-12836 Follow-up from previous version.

Version 2.5.0 (released Mar 8, 2012)

Features and Fixes
  • Gerrit version checking.
    • The plugin fetches the version of Gerrit each time the connection to Gerrit is started.
    • This will be used to filter out functionality that is not available in all Gerrit versions.
    • If a snapshot of Gerrit is used, all functionality will be enabled (as of today, only the file path triggering below uses the version check).
  • JENKINS-12836 Add a Descriptor for the Branch to avoid a warning in the logs.
  • Quiet Period. If a job has a configured quiet period; the trigger will use that if it is larger than the global configuration for the trigger.
  • File path triggering.
    • One or more file paths can now be entered in the config of a Jenkins project, in the same way as Gerrit project/branch.
    • The build will only trigger if the path is found in the patch set for this project/branch.
    • Useful for big gits with lots of smaller modules beneath it.
  • Custom message from workspace file.
    • A workspace file can now be updated with information that will be sent in the message from the trigger to Gerrit.

Version 2.4.0 (released Feb 17, 2012)

Features and Fixes
  • Custom URL per project. Each project can define what URL should be provided in the <BUILD_STATS> information that is sent to Gerrit.
  • JENKINS-11009 Silent Triggered builds now show up in the Manual Trigger monitor panel.
  • EXPERIMENTAL: Cancel old running jobs when a new Patch Set is uploaded on the same change.
    • This feature is set as experimental due to problems we've found during testing. 
    • You can enable the feature from the Manage Jenkins/Gerrit Trigger page.
    • All help in debugging the problems we've found is appreciated, that's why it is in this release. (The problems are described in the comment section on GitHub here).

Version 2.3.1 (released Sep 14, 2011)

Features and Fixes
  • Change owner and patch-set uploader as build parameters.
  • JENKINS-7067 Does not attempt to connect to Gerrit if there is no configuration (first start up)
  • Compatible with git plug-in >= 1.1.10
  • Reload from disk and other duplication related bug-fixes.

Version 2.3.0 (released Mar 31, 2011)

This is built against Jenkins 1.400 to have an easier release process, but it should still be binary compatible with Hudson 1.362+

Features and Fixes
  • JENKINS-7053 Escape quotes in build parameters
  • JENKINS-8578 Added permission-setting to perform "Query and Trigger Gerrit Patches"
  • JENKINS-8799 Administrator check for start/stop the Gerrit connection
  • Ant pattern matching on Windows
  • Allow custom build messages per job
  • JENKINS-7207 Teach the trigger to understand merge commits.

Version 2.2.0 (released Oct 7, 2010)

  New Features
  • Allow for searching and manual triggering of Gerrit Patches - the feature requires Gerrit version 2.1.4 or later, but can be disabled.
    • Known bug: when upgrading from previous release, the manual trigger page is disabled by default. Goto the Gerrit Management page and enable it under the advanced section.
  • Gerrit/GIT Project-name Autocompletion on trigger-config page.
  • Multiple build's results are reported on separate lines to Gerrit instead of "tab separated".
  • Approve commands are queued on a separate thread-pool instead of running on the last build's thread.

Version 2.1.0 (released July 26, 2010)

  New Features
  • JENKINS-6818 Retrigger builds. The users has the ability to retrigger a build. A new build with the same change info as the original build will be scheduled.
  Bugs fixed
  • JENKINS-6967 Missing default parameters.
  • JENKINS-6977 Images and help don't load when Hudson isn't running on the root URL.
  • Fixed some Leaking threads
  • Japanese translation

Version 2.0 (released July 5, 2010)

  • First release.

103 Comments

  1. If the plugin triggers the build but doesn't choose the commit associated with the change which has triggered the build you probably missed to configure the Git plugin correctly ("Choosing Strategy":"Gerrit Hudson Trigger" and "Refspec":"$GERRIT_REFSPEC"). Maybe some validation could help to prevent this mis-configuration (I didn't spot the reason immediately since this configuration setting is hidden behind an "Advanced" button).

  2. Unknown User (jhansche@myyearbook.com)

    The current configuration instructions will cause Hudson to pull the version of the file(s) as of the point when the developer uploaded it, which may actually be out of date (e.g., they branched from remotes/gerrit/master many days ago, and have not rebased since).  The Hudson build will probably succeed, but the Gerrit merge may fail after it's reviewed, causing an unnecessary iteration in the process.

    The way we setup our Hudson projects, in order to catch this kind of error early on, is:

    • URL: ssh://gerrit:29418/Project
    • Name: gerrit
    • Refspec: +refs/heads/master:refs/remotes/gerrit/master
    • Branches to build: master

    This causes Hudson to pull the most recent upstream branch from Gerrit, and then in the first build step, use the "Execute Shell" build step to do a manual cherry-pick of the change:

    #!/bin/sh -x
    git fetch -t gerrit $GERRIT_REFSPEC
    git cherry-pick FETCH_HEAD
    CODE=$?
    if [ ${CODE} -ne 0 ]; then
      git reset --hard remotes/gerrit/master
      exit ${CODE}
    fi
    

    The sh -x causes it not to fail on the first non-success command. We do that because if the cherry-pick fails, it leaves the workspace in an unresolved state, so the next build will fail. Instead, if the cherry-pick fails, we clean up first, by resetting back to the current upstream 'master' ref. So if the cherry-pick fails, the entire job fails and Hudson is able to mark it as "-1 Fails" immediately, without going through the test steps.

    I think having this ability as an option within the Hudson plugin would help save a lot of unnecessarily wasted time while reviewers review code that ultimately can't be merged without a rebase.

    Obviously, Gerrit is the one missing the key feature: reject a submission if it is out of date, requiring a rebase before even submitting. But this is a nice stop-gap for that missing feature. I have also been thinking about ways to give the proper failure reason when Hudson marks the failure in Gerrit. E.g.:

    Patch set 1: Fails
    Failed to merge cleanly. Perhaps you need to rebase?

    git fetch gerrit && git rebase remotes/gerrit/master

    Any suggestions? I tried setting an environment variable at the exit $CODE step, but then reference that variable in the Gerrit trigger configuration didn't seem to transfer properly (it quoted the '$', didn't replace it).

    1. Unknown User (jhansche@myyearbook.com)

      Realized that this extra shell script isn't necessary, if we configure the job as described at the top of this page, and instead enable the "Merge before build" option, to attempt a merge from $GERRIT_REFSPEC onto the "master" branch.  That merge option does a (potential) recursive merge, resulting in a merge commit if the two trees have diverged, which makes it possibly unsuitable for doing a post-build git publish.  But for simply running the unit test job to verify the Gerrit change, it gets the job done.  It will even reset everything back to the master HEAD when it's done.

      1. Joe, could you please share the details of your setup? I'd like to use the same "Merge before build" idea you describe. But if I use 'origin' as the repository and 'master' as the branch to merge to, all my jobs fail with the following error:

        FATAL: null
        java.lang.NullPointerException
        	at hudson.plugins.git.Revision.containsBranchName(Revision.java:58)
        	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:862)
        	at hudson.model.AbstractProject.checkout(AbstractProject.java:1181)
        

        Not quite sure whats going on there.

        1. I'm not sure what would cause that – what happens if you login to the server as jenkins and manually inspect the git workspace? E.g., check remotes, branches, remote branches, etc.

          I don't recall now why, but we ended up moving away from this behavior. It might have been due to the double-execution (mentioned in my comment below) issue, and I tried reverting to the advertised method to see if that would fix it. I've looked into the git plugin more since then, and I think I have a much better understanding of how Jenkins does the git workflow – and based on that, I still believe my method above should work.

          It's possible you're running into a git-plugin bug (not related to gerrit), where the branch specifier doesn't work as expected. At some point in the recent evolution of Jenkins, we started getting build errors, very similar to what you're describing IIRC. And if that's the cause, the fix that we had to put into place on all of our jobs is to change the branch specifier from "master", or "origin/master". Even in our Gerrit-Trigger jobs, we had to set it to "origin/$GERRIT_BRANCH". Try that, see if it fixes the problem for you.

  3. Unknown User (jhansche@myyearbook.com)

    For about a week now, we've been seeing some weird behavior where a single Gerrit change is causing the Hudson Gerrit Trigger plugin to make 3 or more responses to the Gerrit change. In some cases, the first one is marked as "Verified", and the remaining are marked as failed, with no explanation for why it failed, let alone no reason it should have made more than one "approval" for the change. See attached screenshot:

    Another odd behavior is that sometimes it lists other URLs in the failure message for jobs that had nothing to do with that particular triggered job. We also see in some of those Hudson jobs' console outputs, the logs appear to be intermingled with multiple executions of the job – E.g., some log lines have a completely unrelated log line inserted in the middle of it, as if there were two threads appending to the same log file. We can also see two separate "SUCCESS" and "FAILURE" lines in the same console log output. In all cases, the Hudson job on its own should succeed, and there is no explanation for why it is failing anyway.

    Is this a known problem? Any workaround, or some way to fix it, or find out what is causing it?

    1. Unknown User (jhansche@myyearbook.com)

      Here's an example of the case where it shows 2 URLs -- the original URL was job #70, which initially succeeded, then failed several times.  When I clicked Retrigger in Hudson, the new job succeeded, and marked it as Verified, but the last message displays two URLs: one for job #70, and one for the retriggered job #72.  It shows that both jobs are "SUCCESS", but in Hudson, #70 is marked as a failure, and #72 is successful.  The behavior is totally unexpected and unexplainable.

      1. I'm seeing a very similar behavior. In my case a single trigger executes the appropriate job at the appropriate git revision and simultaneously appears to re-execute an earlier unrelated build at its corresponding git revision. It appears that both of these jobs are executing simultaneously and my tests generally fail because of the strange state left behind by two builds of two versions of my software being attempted in the same directory.

        I hope that someone out there has encountered and fixed this.

        1. FWIW, I ended up finding the culprit in our environment: we still had an older Gerrit+jenkins plugin that was trying to compete with this Gerrit Trigger plugin. Once I identified that as the problem and disabled it, things went back to normal. Check your "Installed Plugins" to see if you have more than one Gerrit-related plugin installed, and see if disabling the other one helps.

  4. I have a maven project and it has two jenkins jobs: A gerrit and non-gerrit build.  The non-gerrit one is for testing master itself and for doing releases, but you can't easily do releases because it doesn't set the gerrit hook (that adds Change-Id lines to the comment messages).  And maven builds don't let you add arbitrary commands to the build. :-(

    I'm working around it by hand, at the moment, but it's pain.

    Can you either add to this plugin or add another plugin that fixes this? That'd be great.

  5. In chapter "Usage with the Git Plugin", better to mention $GERRIT_REFSPEC will be automatically set by gerrit trigger plugin.

    Also could mention, click "Parameters" in finished build to see all internal parameters.

    And also it is little difficult to find "Advanced" button when I try to set "Gerrit Trigger" for "Choosing strategy"

  6. When loggin in the management pane I get the error "The connection to Gerrit is down! Check your settings and the Gerrit server."

    However when going into the gerrit trigger plugin page and hitting the test connection button it works fine.

    I know that gerrit is up and functioning.

  7. We are using modules (with Ivy plugin) in our Jenkins job which is started with Gerrit trigger. The problem is that the main job is marked successful immediately when the first module is started and this creates ok label in Gerrit. After all modules are built and some of them fails the main job is marked as failed but this is too late for Gerrit as the change is already marked as ok.

    What we would like to see is that the main job waited as long as all modules are built and only then reported the status to Gerrit. Any suggestions how to achieve this?

  8. We are using this plugin for our CI.The problem I encounter is that I can only send the build start message.No successful message for building successfully or failed message for building failed.Just like this:

    public jenkins

    Patch Set 1: Test Build Started …

    9:36 AM

    public jenkins

    Patch Set 1: Test Build Started …

    9:56 AM

    public jenkins

    Patch Set 1: Test Build Started …

    9:58 AM

    public jenkins

    Patch Set 1: Test Build Started …

    10:01 AM

    public jenkins

    Patch Set 1: Test Build Started …

    10:32 AM

    I have checked the parameters very carefully and could not find any defect.

    I also find that when I change the value in "Gerrit Reporting Values" from 1 to 0. I can get the successful message sent. But the build command is only "ls".

    Can you give me some suggestions?

    1. Run into the same problem today. Took me some hours to find the "bug". Make sure that your jenkins user (public jenkins) within gerrit is in the group which has the "Label Verified" rights.

      1. Yes,you are right.Thank you!

  9. I have a question about Jenkins's Gerrit Trigger. 
    Many gerrit processes are running in machine. 
    If new change-set in code review is registerd, the build is performing and given 'Verified +1'. 
    However I am able to add just a single gerrit server only in Jenkins like the below.. 
    Jenkins manage > Gerrit Trigger 
    Gerrit Server 
    Hostname 
    Frontend URL 
    SSH Port 
    Username 
    SSH Keyfile 
    SSH Keyfile Password 
    Is there any way to register the multiple gerrit processes in Gerrit Trigger?
    Please help.
    I have a question about Jenkins's Gerrit Trigger. 

    Many gerrit processes are running in machine. 

    If new change-set in code review is registered, the build is performing and given 'Verified +1'. 

    However I am able to add just a single gerrit server only in Jenkins like the below.. 

    Jenkins manage > Gerrit Trigger 

    Gerrit Server 

    Hostname 

    Frontend URL 

    SSH Port 

    Username 

    SSH Keyfile 

    SSH Keyfile Password 

    Is there any way to register the multiple gerrit processes in Gerrit Trigger?

    Please help.

    1. It is not possible to do today.

      The feature has been requested before and it was started by a member in the community, but time constraints ended that effort.

      If anyone is interested in implementing it contact me via the dev list or directly via mail and I'll give some pointers in how I think it can be achieved.

  10. I have a question regarding the "Query and Trigger Gerrit Patches" screen from the main Jenkins menu:

    It would appear that we have Gerrit Trigger configured correctly as we can start a build with it, use google repo to update the build engine with the patch set, run the build and post back to Gerrit using Jenkins as the verifier.

    However, at one point I wanted to re-trigger a build, and, before I found that there was a retrigger button in the build workspace, I tried using the "Query and Trigger Gerrit Patches" screen.

    I had expected that if I entered "status:open" in the search window then I would have had listed the Gerrit patches that I could then, perhaps, manually retrigger. But, whatever I enter in the search box gives me nothing (I just get a blank search box again). Is this expected behaivior? Do you have a search string that should give me something? Or, is there something amiss with our configuration?

    Gerrit: 2.2.1 / Jenkins: 4.38 / Gerrit Trigger: 2.3.1

    Thanks, Andrew. 

    1. It sounds as if you have something wrongly configured, but at the same time if the auto triggering works then it should work to make queries also. Maybe you have made some security settings in Gerrit that hinders the querying to be done.

      Try to make a query from the command line with the same username and public key that you have for Jenkins and see what type of response you get.

  11. It would be very nice to be able to append the number of warnings (from the Warnings Plugin) to the verify message. Is this somehow possible?

    1. I agree it would be nice to be able to customize the approval comment in general. E.g., it would be nice to be able to differentiate a failure due to compiler error, vs a failure due to unit tests, vs some other failure (like malformed commit messages), etc. Right now the only way to know why it failed is to follow the Jenkins URL, and inspect the Console log, to see where the failure occurred (which can be very difficult to track down, at times).

      But given the way the plugin works, where it will post all approvals/comments at one time after all jobs have completed, that's not a simple thing to do. I suppose the Trigger config could have an option to set an "Approval comment override" file path, where if the file exists and contains text, it can add that to a comment buffer. For example, right now it shows each Jenkins build URL, followed by SUCCESS or FAILURE. If that "comment override" file does exist and contains text, it could append that comment immediately following that URL. Though that wouldn't work for something like where an "Ant task" build step fails, I would consider using it for something more like this, in an execute shell step:

      /usr/local/bin/jenkins-check-commit-messages.sh > ./gerrit-comment.txt
      

      or:

      make all
      
      if [ $? -ne 0 ]; then
          echo "Failed to compile!" > gerrit-comment.txt
      fi
      
      1. That sounds like a simple enough feature, there is already a "custom message per job" feature so adding this shouldn't be too hard.

        For example a post buildstep (like a recorder) that looks for a file and when the trigger then looks for a custom message it also checks if the recorder has found anything.

        Anyone interested in developing it?

        1. Shouldn't be hard to implement.. I'll try to get to it this week.

    2. I've heard some rumor that Gerrit will get command line support for adding line comments, if it hasn't got it already. When that happens my long term plan was to add an extension point to the Gerrit trigger plugin so that other plugins like checkstyle and findbugs can provide line comments from their analysis directly into Gerrit.

  12. We've got the gerrit trigger plugin working well at verifying checkins - actually too well...

    Some gerrit checkins trigger several verification jobs.  Each of these verification jobs is logging a "starting" message into the gerrit checkin, and that in turn causes an email to every checkin reviewer.  Is there a configuration option to completely eliminate the "starting" messages, thereby reducing the clutter in the  gerrit review entry and also the amount of email being sent to reviewers?

    Note: we originally fired a single job for the gerrit checkins that ran an entire tree of verification tests, but that caused complications with a coverage plugin.

    Thanks...

    1. Tried a few things to stop this aswell.
      In the end the 'hack' we use is to replace the default Gerrit Verified Started Command "gerrit approve ..." with "gerrit ls-projects" - works well.

      No reason why we chose ls-projects, just needed any gerrit cmd to keep the trigger happy.

      Would be nice to have a inbuilt option todo this however.

    2. A new option to the approve command came in to the Gerrit trunk the other day called --supress-message or something similar. It basically tells Gerrit not to send out a mail about this particular comment.

      It's not in any release yet, but probably in the near future.

  13. Going back to having a single job which is gerrit-triggered, so less noise in the gerrit review and in email.  The coverage data generated by the single gerrit validation job will be picked up by subsequent ("build after other projects are built") jobs.  That should solve it...

  14. How to allow "Build Now" and "Retrigger" to work? Once setup for Gerrit the normal Build should use a branch by default, or that button should be removed.

    1. Added a "Tips and Tricks" section above where I describe how to solve this.

  15. Have you considered adding support for multiple Gerrit servers? We are in that situation today and unfortunately a given Jenkins master can speak to only one Gerrit. As a result we will need to spin up several Jenkins masters and ideally we'd like to avoid that.

    1. I had considered it. When I made the original design I did some preparation work to make it relatively easy to extend it to allow for multiple Gerrit servers.

      Internally at my workplace we only have one central Gerrit server and it is at it seems today never going to change. So we will never get that feature prioritized to implement it.

      But if anyone else is interested in giving it a try I welcome it and will try to give as many hints as I can to help out. I think Brad or Anthony on the dev list started that work a long while back, but other priorities stopped that work as well. And since I never got to fully need the feature in the beginning other newer parts of the plugin won't be as easily bent towards supporting it, but it is still possible, it just needs more work than a few lines of code.

      1. OK, this is good news then. I am willing to put some time aside to do the work because it is a feature that we really need at the moment. Actually, my most significant road block isn't technical: I need to get approval for collaborating that work out.... I will get back in touch with you when I get the clearance.

  16. I find I get the error:

    FATAL: Null value not allowed as an environment variable: GIT_BRANCH
    

    unless I set the job's Git section's 'Branches to build' field to (literally) $GERRIT_BRANCH (as shown by expanding one of the line-items from a 'Trigger Gerrit event manually'), instead of leaving it blank as the instructions above said.

    I didn't realise I could edit the page above, so I've added a note about it in the appropriate section, but I've weaselled it with 'maybe' because I don't know whether it's supposed to be required or not. It'd be good if someone in the know could make it defininitive.

    Thanks.

    1. I became the similar phenomenon, too.

      Our CI Ver, Jenkins ver. 1.451 + Git Plugin 1.1.15 + Gerrit Trigger 2.4.0

      The workarounds to a problem were as follows.

      * Choosing strategy = Default  

      1. Addition.
        I can judge Gerrit-Trigger in the Gerrit side.
        Also, don't fail in the build either.

        But,
        I knew the problem that Commit Message was not displayed by a build history of Job.

        But as a small problem. . .

        Its cause

        By changing this to $GERRIT_PATCHSET_REVISION,
        Now can also be used: "Gerrit Hudson Trigger on the Choosing strategy".

        Because I was able to display it to Commit Message when it is the following methods, I list the result that I examined.

        Slaves: (Win xp 32bit, Win7 64bit, Linux)

        git : Refspec

        $GERRIT_REFSPEC  (Win xp 32 :  "${GERRIT_REFSPEC}"  )

        Branches to build:

        Branch Specifier (blank for default):  $GERRIT_PATCHSET_REVISION or "origin/master | master" (Default is bad)

        Choosing strategy

        Gerrit Hudson Trigger

        Build Trigger

        Gerrit Event: Plain= repo-name ,  Path= **

  17. I'm getting a weird error. It says my version of Gerrit is a bit old (which is partially expected). But then it says "Trigger on files requires 2.2.3"

    But 2.2.3 doesn't seem to be a valid Gerrit version. I think it should be 2.3.

    Additionally I think it would be good if it told you what version of Gerrit it detected.

    1. Fixed it in the latest release, thanks for noticing.

      When we designed the feature there where rumors that a 2.2.3 version was planned and that the --files option would be in that version. But they changed their minds and released 2.3 instead.

  18. How did you set it so it only builds on merged commit instead of status:open changes?

    1. It's in the works.

      Keep an eye on https://github.com/jenkinsci/gerrit-trigger-plugin/pull/21 where "trigger on change merged" is included.

      1. We're trying to use git polling to workaround this missing feature, but its running in an infinite loop. Apparently jenkins git polling changes is not working when combined with gerrit. We use $GERRIT_BRANCH and $GERRIT_REFSPEC in our git SCM config, which are parameterized and defaulting to 'master' and 'refs/heads/master' respectively. Anybody has some tips?

      2. We're trying to use git polling to workaround this missing feature, but its running in an infinite loop. Apparently jenkins git polling changes is not working when combined with gerrit. We use $GERRIT_BRANCH and $GERRIT_REFSPEC in our git SCM config, which are parameterized and defaulting to 'master' and 'refs/heads/master' respectively. Anybody has some tips?

  19. I am having a problem with the combination of Git + Gerrit + Ant build, specifically for building an Android application. I have a CentOS machine that I installed Ant version 1.8.3 (the default one 1.6 does not work well the Android version 15). Gerrit seems to work, since I am able to retrieve the change sets from gerrit and also able to manually trigger a build from "Query and trigger gerrit patches" section. In the Ant settings, I have set the target as "release".

    Once I trigger the build, a wrong target seems to be passed on to the ant command line, instead of "release". The output I get is something like:$> apache-ant-1.8.3/bin/ant -file build.xml '-DGERRIT_PATCHSET_UPLOADER="My Name" <my.name@example.com>' -DGERRIT_CHANGE_URL=https://mygerritserver/9 -DGERRIT_CHANGE_ID=I41aff7d72d5d0cc1e19a12944788b7890a62adce -DGERRIT_CHANGE_NUMBER=9 "-DGERRIT_PATCHSET_UPLOADER_NAME=My Name" "-DGERRIT_CHANGE_SUBJECT=Added build.xml for project" -DGERRIT_PATCHSET_UPLOADER_EMAIL=my.name@example.com -DGERRIT_BRANCH=master -DGERRIT_REFSPEC=refs/changes/09/9/1 -DGERRIT_PATCHSET_NUMBER=1 "-DGERRIT_CHANGE_OWNER_NAME=My Name" -DGERRIT_PATCHSET_REVISION=41aff7d72d5d0cc1e19a12944788b9690a62adce -DGERRIT_PROJECT=myproject '-DGERRIT_CHANGE_OWNER="My Name <my.name@example.com>' -DGERRIT_CHANGE_OWNER_EMAIL=my.name@example.com -Dsdk.dir=/jenkins/android-sdk-linux release
    Buildfile: /usr/share/tomcat5/.jenkins/workspace/myproject/build.xml

    BUILD FAILED
    Target "Name <my.name@example.com>" does not exist in the project "myproject".

    I have tried triggering the build without gerrit (after removing $GERRIT_REFSPEC setting), and the correct target is passed to ant. Looks like only with Gerrit, I get this kind of error.
    Any help?

    1. I figured out the cause of problem. The name of the GERRIT user is sent without a forward slash, i.e., if I manually run the ant command with the change:

      '-DGERRIT_PATCHSET_UPLOADER=\"My Name\" <my.name@example.com>'

      and

      '-DGERRIT_CHANGE_OWNER=\"My Name\" <my.name@example.com>'

      ant runs fine and the build succeeds. But I am not sure why gerrit plugin(!?) does not send these forwards slashes.

  20. I have a problem to use this plugin.

    Here is the System environment,

    Ubuntu 10.04

    Jenkins LTS v1.447.1

    Git plugin v1.1.8, 

    Gerrit Trigger plugin v2.5.2

    Gerrit 2.3

    I have been followed the tutorial showed below and tried to search this issue in the Internet.

    But I can't find out any solution.

    In addition, I can get the patch information from Gerrit by the "Query and Trigger Gerrit Patches", but Jenkins can't get the GERRIT_REFSPEC. 

    The following is my polling log, any help?

    --------

    Using strategy: Gerrit Trigger

    Fetching changes from 1 remote Git repository

    Fetching upstream changes from ssh://jenkins@localhost:29418/projects/test.git

    ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway

    hudson.plugins.git.GitException: Command "/usr/local/bin/git fetch -t ssh://jenkins@localhost:29418/projects/test.git $GERRIT_REFSPEC" returned status code 128:

    stdout: 

    stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC

    at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:779)

    at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:741)

    at hudson.plugins.git.GitAPI.fetch(GitAPI.java:190)

    at hudson.plugins.git.GitAPI.fetch(GitAPI.java:987)

    at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:811)

    at hudson.plugins.git.GitSCM.access$100(GitSCM.java:90)

    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1095)

    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1063)

    at hudson.FilePath.act(FilePath.java:839)

    at hudson.FilePath.act(FilePath.java:821)

    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1063)

    at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)

    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)

    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)

    at hudson.model.Run.run(Run.java:1434)

    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)

    at hudson.model.ResourceController.execute(ResourceController.java:88)

    at hudson.model.Executor.run(Executor.java:239)

    1. My guess is that you are trying to build via the "Build Now" link in Jenkins.

      The job should be triggered by a new patchset in Gerrit or via the Trigger button on the "Query and Trigger Gerrit Patches" page.

      If you want to just build the latest commit on master; look at the "Tips & Tricks" section on this wiki page.

      1. Thanks for your reply!
        My purpose is the Gerrit Trigger can detect the new patchset automatically, and then auto build the job.
        I try to trigger the build in the "Query and Trigger Gerrit Patches" page, but also got the fail.
        I also try to add the String parameter "GERRIT_REFSPEC" in the job configuration, but got the fail, too.
        My job configuration is, 
        Repository URL: ssh://jenkins@localhost:29418/projects/test.git
        Refspec: $GERRIT_REFSPEC
        Config user.name Value: jenkins
        Config user.email Value: jenkins@localhost
        Choosing strategy: Gerrit Trigger
        In Gerrit event, 
        Gerrit Project [Plain]: projects/test
        Branches [Plain]: **
        Poll SCM: * * * * *

  21. We have *almost* everything working with Gerrit-Trigger, Gerrit and Jenkins. Gerrit-Trigger is pulling in patchsets and sending the message to Gerrit saying it's starting. Jenkins is building, but post-build Gerrit-Trigger isn't sending a message to Gerrit. I don't see any Gerrit-Trigger option in the post-build drop down in Jenkins. What am I missing? Is there a Gerrit-Trigger log I could look at to help track down the issue?

    Platform:

    Ubuntu 12.04, Gerrit 2.3, Jenkins 1.470, Gerrit-Trigger 2.52

    1. Figured it out, FYI for others who make the same mistake, make sure the user that Gerrit-Trigger connects to Gerrit with has the Label Verified access in Gerrit...doh!

  22. Unknown User (realgsong@hotmail.com)

    Is there a way to build patches over multiple project together?

    I'm using repo and there's a project of core-framework and others of applications. Sometimes we need to fix framework and application altogether. In that case, gerrit will look like

    ID

    Subject

    Owner

    Project

    Branch

    Updated

    V

    R

     

     

    I5e6af241

    This fixes #844

    gsong

    frameworks

    master

     

     

     

     

     

    I43cf5ea3

    This fixes #844

    gsong

    MyApplication

    master

     

     

     

    Now gerrit trigger start build one by one. The 2nd one in 'MyApplication' always get failed. What I want is build them together. so that it can guarantee that build is not broken afterall. Is there a solution for this problem? Thank for reading.

  23. Another Question. In a specific branch, jenkins should Verify, Review AND Submit. I could do that via the global gerrit settings under "Gerrit Verified Commands". But i only want it for a specific branch. The plugin, right now, only allows in the job configuration to change the "message", it would be nice to also change the "command". Or did i miss something?

    1. Found a workaround. In the global configuration:

      replace
          gerrit approve <CHANGE>,<PATCHSET> --message 'Build Successful <BUILDS_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW>
      with
          gerrit approve <CHANGE>,<PATCHSET> --message 'Build Successful <BUILDS_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW> $GERRIT_SUBMIT_ENTRY
      

      In the job, where you want to submit via jenkins. Inject the environment variable "GERRIT_SUBMIT_ENTRY" with Value "--submit". (smile)

      1. looks like a typo: s/$GERRIT_SUMMIT_ENTRY/$GERRIT_SUBMIT_ENTRY/

        1. you are right. corrected it.

  24. I'd like to trigger a build when a change is accepted and merged in the Gerrit UI and when something is pushed to refs/heads/*.
    Right now all I managed to do, is to trigger a build when the change is pushed to gerrit refs/for/refs/heads/...
    Is this possible with Gerrit trigger, and if so, how?

    Thank you

    1. why triggering it via gerrit? you could create a jenkins job, which "ask" the git repo for changes and if so, jenkins will trigger the job.

      1. Thank you for the suggestion, I did set it up with polling: I look at changeSet and if there is no change I don't do the rest of the job. The issue is that I'm not going to poll every second, so there is conspicuous delay, and I'm pretty sure the discrepancy between what's in Gerrit and what has been built will trip up someone down the line.

    2. The next version (2.6.0) will provide the ability to trigger on "change merged", "comment added" and "draft-published" events.

      We are currently working on a new release, we just have some small kinks left to fix.

  25. I am trying to make Gerrit trigger to trigger build automatically but so far it does not do anything.

    Here is my setup : Jenkins 1.455, Gerrit trigger plugin version 2.5.2, Gerrit version 2.4.2

    When I stopped and started Gerrit daemon, I see in the jenkins.log:

    Sep 18, 2012 9:39:56 AM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
    INFO: Starting Up...
    Sep 18, 2012 9:39:56 AM com.sonyericsson.hudson.plugins.gerrit.trigger.version.GerritVersionChecker createVersionNumber
    SEVERE: Gerrit version number is null or the empty string.
    Sep 18, 2012 9:39:56 AM com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
    INFO: Ready to receive data from Gerrit

    ...

    I also see numerous lines of:

    INFO: Parsing private key file
    Sep 18, 2012 9:29:42 AM com.sshtools.j2ssh.transport.publickey.SshPrivateKeyFile parse
    INFO: Private key is not in the default format, attempting parse with other supported formats

    I followed this blog: http://www.infoq.com/articles/Gerrit-jenkins-hudson&nbsp;

    I used list "**" for project and list "**" for branch and still it is not triggered.

    When I tried "Query and Trigger Gerrit Patches", I can query with "is:open" and found the patch set.  When I triggered build for that patchset, it did not run. 

    Triggering Builds:  "No jobs triggered for this event"

    If I build the job manually with "Build Now" by adding default parameter:Add a String parameter called GERRIT_REFSPEC with the default value refs/heads/master

    I can build from refs/heads/master but the build failed because the patch set submitted to refs/for/master is not yet merged. I am expecting Gerrit trigger
    to trigger the build as soon as patch set is submitted.

    I have ensured that the user used by gerrit-trigger to connect to gerrit is in "Non-Interactive Users" group and it is given Label Verified permission
    on refs/, refs/heads/.

    Is it SSH key issue? There is no error in stop/start Gerrit-trigger daemon. The connection test also passed.

    Any hints is greatly appreciated. This is POC and we would like to move it to production if we can demo Jenkins/Gerrit Integration with Git to
    dev teams.

    Thanks.
    -Indra

    1. I have exactly the same issue. Did you manage to resolve this?

      1. A standard mistake that people do when configuring "**" on branches is that they forget to change from Plain to Path for the comparator. So the comparison would still do a plain text check which fails.

        The parsing private keyfile in the log is a leftover debug logging from when you visit the management page, so nothing to worry about there.

  26. I'm having a problem with failing builds that are triggered:

    [JOBNAME] $ cmd.exe /C '"c:\jenkins\tools\Ant\Ant1.8.4\bin\ant.bat "-DGERRIT_PATCHSET_UPLOADER=\""FIRSTNAME LASTNAME\"" <emailaddy@domain.com>" -DGERRIT_CHANGE_URL=http://gerrit.domain.net/186523 -DGERRIT_CHANGE_ID=I174269fea6e64daf2b8752b15e7831dd824541c6 -DGERRIT_CHANGE_NUMBER=186523 "-DGERRIT_PATCHSET_UPLOADER_NAME=FIRSTNAME LASTNAME" "-DGERRIT_CHANGE_SUBJECT=This is the subject of my change" -DGERRIT_PATCHSET_UPLOADER_EMAIL=emailaddy@domain.com -DGERRIT_EVENT_HASH=621616435 -DGERRIT_BRANCH=BRANCHNAME -DGERRIT_REFSPEC=refs/changes/23/186523/1 -DGERRIT_PATCHSET_NUMBER=1 "-DGERRIT_CHANGE_OWNER_NAME=FIRSTNAME LASTNAME" -DGERRIT_PATCHSET_REVISION=d4b5a7e04cf927a7ffbcde139685b95ec579e08c -DGERRIT_PROJECT=git/project "-DGERRIT_CHANGE_OWNER=\""FIRSTNAME LASTNAME\"" <emailaddy@domain.com>" -DGERRIT_CHANGE_OWNER_EMAIL=emailaddy@domain.com clean dist && exit %%ERRORLEVEL%%"'
    Buildfile: c:\jenkins\workspace\JOBNAME\build.xml

    BUILD FAILED
    Target "LASTNAME" <emailaddy@domain.com>" does not exist in the project "PROJECTNAME".

    It looks to me like there is an extra " added that is causing this.

    Can anyone help?

    ANT 1.8.4

    Latest Gerrit Plugin and Jenkins version

    Windows 2008 Slave

    Thx

  27. Hi, i have this problem:

    Started by user Lyubomira Valcheva

    Building remotely on user in workspace d:\jenkins\workspace\DONE

    Checkout:avatar_sod_gerrit_voter / d:\jenkins\workspace\DONE - hudson.remoting........:user

    Using strategy: Default

    Cloning the remote Git repository

    Cloning repository origin

    ERROR: Error cloning remote repo 'origin' : Could not clone ssh://............/......../..................git

    hudson.plugins.git.GitException: Could not clone ssh://git.n.plugins.git.GitAPI.clone(GitAPI.java:268)

                    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1122)

                    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064)

                    at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2196)

                    at hudson.remoting.UserRequest.perform(UserRequest.java:118)

                    at hudson.remoting.UserRequest.perform(UserRequest.java:48)

                    at hudson.remoting.Request$2.run(Request.java:326)

                    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)

                    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                    at java.util.concurrent.FutureTask.run(Unknown Source)

                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                    at hudson.remoting.Engine$1$1.run(Engine.java:60)

                    at java.lang.Thread.run(Unknown Source)

    Caused by: hudson.plugins.git.GitException: Command ""C:\Program Files (x86)\Git\bin\git.exe" clone --progress -o origin ssh://git……………….git d:\jenkins\workspace\Done" returned status code 128:

    stdout: Cloning into 'd:\jenkins\workspace\DONE'...

    stderr: Permission denied (publickey).

    fatal: The remote end hung up unexpectedly

                    at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:855)

                    at hudson.plugins.git.GitAPI.access$000(GitAPI.java:40)

                    at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:264)

                    at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:244)

                    at hudson.FilePath.act(FilePath.java:842)

                    at hudson.FilePath.act(FilePath.java:824)

                    at hudson.plugins.git.GitAPI.clone(GitAPI.java:244)

                    ... 13 more

    Trying next repository

    ERROR: Could not clone repository

    FATAL: Could not clone

    hudson.plugins.git.GitException: Could not clone

                    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1134)

                    at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064)

                    at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2196)

                    at hudson.remoting.UserRequest.perform(UserRequest.java:118)

                    at hudson.remoting.UserRequest.perform(UserRequest.java:48)

                    at hudson.remoting.Request$2.run(Request.java:326)

                    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)

                    at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                    at java.util.concurrent.FutureTask.run(Unknown Source)

                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                    at hudson.remoting.Engine$1$1.run(Engine.java:60)

                    at java.lang.Thread.run(Unknown Source)



    i checked the .ssh directory, the keys, registration on Git, everything seems ok. Please Help!

    1. Have you registered the user account used only for build on Gerrit?  Have you added it to Non-Interactive user group on Gerrit?

      in the git URL use as such:  ssh://<gerrit-build-user>@<gerrit-hostname>....git

      The <gerrit-build-user> here is the user you have registered for non-interactive purpose i.e. to use with git cloning from Gerrit repo.

      -Indra

      1. O.k. I put the name but there is another error:

        d:\jenkins\workspace\DONE

        Checkout:avatar_sod_gerrit_voter / d:\jenkins\workspace\DONE - hudson.remoting.Channel@a27d00a:

        Using strategy: Default

        Cloning the remote Git repository

        Cloning repository origin

        Fetching upstream changes from ssh://hudsonvoter@git…………...git

        ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway.

        hudson.plugins.git.GitException: Command ""C:\Program Files (x86)\Git\bin\git.exe" fetch -t ssh://hudsonvoter@git………….git $GERRIT_REFSPEC" returned status code 128:

        stdout:

        stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC

                at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:855)

                at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:817)

                at hudson.plugins.git.GitAPI.fetch(GitAPI.java:197)

                at hudson.plugins.git.GitAPI.fetch(GitAPI.java:1063)

                at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1142)

                at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064)

                at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2196)

                at hudson.remoting.UserRequest.perform(UserRequest.java:118)

                at hudson.remoting.UserRequest.perform(UserRequest.java:48)

                at hudson.remoting.Request$2.run(Request.java:326)

                at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)

                at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                at java.util.concurrent.FutureTask.run(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                at hudson.remoting.Engine$1$1.run(Engine.java:60)

                at java.lang.Thread.run(Unknown Source)

        ERROR: Could not fetch from any repository

        FATAL: Could not fetch from any repository

        hudson.plugins.git.GitException: Could not fetch from any repository

                at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1154)

                at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1064)

                at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2196)

                at hudson.remoting.UserRequest.perform(UserRequest.java:118)

                at hudson.remoting.UserRequest.perform(UserRequest.java:48)

                at hudson.remoting.Request$2.run(Request.java:326)

                at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)

                at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                at java.util.concurrent.FutureTask.run(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                at hudson.remoting.Engine$1$1.run(Engine.java:60)

                at java.lang.Thread.run(Unknown Source)

  28. I found that our job configuration is often changed automatically. Our original setting is as following:
    However, The setting of "Choosing strategy" is often changed automatically from "Gerrit Trigger " to "Default". And the change happened randomly. We had to 

    set the option manually from time to time. We are so confused. Is there anyone who has the same experience ? 

    1. Others seems to have had this as well, there is a Jira issue reported on it.

  29. I want to post additional message to gerrit when vote. I set the Gerrit verify commands in gerrit trriger like ''' gerrit approve <CHANGE>,<PATCHSET> --message "Build Successful <BUILDS_STATS> $BUILDS_MSG" --verified <VERIFIED> --code-review <CODE_REVIEW> ''' , and export the variant $BUILDS_MSG in build.sh like  '''export BUILDS_MSG="....." ''', but the message post to gerrit just contains a string '$BUILDS_MSG' , not the string I exported in build.sh. build.sh is the shell script used to build the job.

    who can tell me how to use the command line variant to post additional message to gerrit , and the variant in single quotes, double quotes, and none quotes which will be transformed ?

    1. export is only valid for the process that it is made in and any sub processes, since Jenkins is the parent of the script where the export is made it is not propagated up to the build.

      Behind the advanced button on the trigger config section you have several options for sending custom messages to Gerrit. Either you could just type a string into one of the custom build messages fields or you can specify a pattern to a file in the "Unsuccessful Message File" setting. Your build could then write something to that file and the text would be sent in along with the build status.

      1. Thanks, I get it. Maybe additional message for successful builds is not needed, I have changed these as failed builds and post the reason to gerrit.

        More, someone may upload a wrong change and abandon it soon after, the patchset create event will trigger a builds for my job setttings, could I remove the builds from queue or interrupt the builds in process? How to? There is no event about abandon and restore.

  30. In Query and Trigger Gerrit patches of Jenkins, when i add query string then I found charactors were broken like below.
    ==================================================================================================================================================
    Expected a ',' or '}' at character 147 of {"project":"QE_demo","branch":"master","id":"I9eff9d5a1fc40d2dc8b41fc3519fdd705463530e","number":"167","subject":"test 4","owner":

    Unknown macro: {"name"}

    ,"url":"http://text.lge.com/itl/gerrit/167","createdOn":1369118470,"lastUpdated":1369118470,"sortKey":"002534b1000000a7","open":true,"status":"NEW","currentPatchSet":{"number":"1","revision":"9eff9d5a1fc40d2dc8b41fc3519fdd705463530e","ref":"refs/changes/67/167/1","uploader":

    Unknown macro: {"name"}

    ,"createdOn":1369118470},"patchSets":[{"number":"1","revision":"9eff9d5a1fc40d2dc8b41fc3519fdd705463530e","ref":"refs/changes/67/167/1","uploader":

    Unknown macro: {"name"}

    ,"createdOn":1369118470}]}
    ================================================================================================================================================
    If it works fine, there is table listed patches in the gerrit, but i don`t know why charactors are broken.

    I wonder if there is mismatching between Gerrit trigger version in jenkins and gerrit.
    Actually, Gerrit trigger installed version 2.9 and gerrit code review version is 2.4.1.
    I tried to downgrade Gerrit trigger in jenkins, but there was not downgrade button.
    How can i solve this problem?

    1. I think you tag designated and put in place can downgrade.

      https://github.com/jenkinsci/gerrit-trigger-plugin/tags

      You can upload from the Plugin Manager for Jenkins.

      1.  I downloaded gerrit-trigger-plugin-gerrit-trigger-2.5.0.zip file from https://github.com/jenkinsci/gerrit-trigger-plugin/tags.

        --> In Plugin Manager for Jenkins, it needs .hpi file, but i can not find any .hpi file gerrit-trigger-plugin-gerrit-trigger-2.5.0.zip.

        Could you explain to add gerrit previous version in the Plugin Manager?

        1. Sorry for the late reply.

          I was able to create hpi file.

          Have not tried is just below.

          • Ver2.5
          • verified to work

          FYI ) I have build hpi steps (a little fit 2.5)

          1. Clone from Github
          2. Version changes in the position of the tag (I think that even a zip file is the same.)

            e.g.) Use of git tag
            $ git tag -ln | grep 2.5

            confirm of hash.
            $ git rev-parse gerrit-trigger-2.5.0

            check out.
            $ git checkout -b 2.5 ccd34c87fa13bb21c47169a95957358bd9c09e5d
            (git checkout-b local-branch tag-hash)

            confirm
            $ git branch
            $ git log --decorate=short 

          3. Maven Install http://maven.apache.org/
            Build run https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
          4. When I've done at 2.8 a bit changed the pom.xml.
          5. gerrit-trigger.hpi creation

          I hope the best for you.

      2. Previous versions for all plugins can be found in the Jenkins maven repo.

        Direct url to GT is http://repo.jenkins-ci.org/releases/com/sonyericsson/hudson/plugins/gerrit/gerrit-trigger/

    2. There are no correlations between the versions of Gerrit and the Jenkins Gerrit Trigger plugin, they are two separate projects maintained by different people.

    3. In this problem, Only 'KOREAN' word is broken.

      Is it encoding problem? How can i set the encoding in jenkins to UTF-8?

      I installed jenkins in stand alone mode, not with tomcat...

      I tried to find encoding information in system variables or enviornment variables.. but i could not find.

      How do i fix 'Korean' word broken problem in jenkins?

  31. I'm experimenting with Gerrit, and I am unsure how to do something, or even if I'm going about things the right way.

    I'd like to have a single job which builds a project with mvn clean install when it's just a draft change set, and with mvn clean deploy if it's a merged/published changeset.

    My thought is that any changeset would get a build of just those changes with clean install and Jenkins would vote +1/-1 on the Verified label. The changes aren't pushed to our local nexus server.

    Then, when the review is completed and someone hits the publish button, gerrit merges the change and Jenkins builds with clean deploy so that the changes are pushed to our local nexus server and others can download that snapshot.

    Is there any way to do this other than with two different build jobs in Jenkins?

  32. HI I found Gerrit Trigger plugin alaways  trigger one build on  two buildslave,the gerrit commit ID is one,like this:
     
    and also trigger one job  two time for  two gerrit ID at the same time,I just set my all slave  for buildslave_group,and use the group

  33. I'm sorry if this is a plainly obvious question but for the "build now" tip to start a manual build the directions state:

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

    where exactly does one add this?

  34. Hi all! any news/feedback on 2.11.0-beta-4 ?

  35. If you are having issues sending any review comments to Gerrit, after investigation I found using the command line feature of Gerrit that you need to remove the verified flag from the default 'Gerrit Verified Commands'.

    I'm building Gerrit from source at the date of this post and suspect it will affect the current release candidate Gerrit 2.10-rc0

    Steps in Jenkins..

    Manage Jenkins > Gerrit Trigger > [select your gerrit server] > Advanced

    edit all lines that include the --verified flag, for example..

    gerrit review <CHANGE>,<PATCHSET> --message 'Build Started <BUILDURL> <STARTED_STATS>' --verified <VERIFIED> --code-review <CODE_REVIEW>

    to

    gerrit review <CHANGE>,<PATCHSET> --message 'Build Started <BUILDURL> <STARTED_STATS>' --code-review <CODE_REVIEW>
  36. Hi, the Gerrit Trigger plugin allows you to create multiple jobs with the same criteria, and it will automatically join the results together before publishing results into Gerrit.

    How I can cancel the automatic join of the results so I will have result per job for the same trigger ?

  37. I want to trigger job only when specific reviewer is added
    this option not exist or I not familiar with it, in the trigger, anyone now a way to do it ?

  38. I'm having a bit of a problem - recently modified a working CI build to get it to ignore changes to files in the doc directory. I did this by changing the Gerrit Trigger part of the config; adding a "forbidden file path" of

    **/doc/**
    

    I then went and created a new job to process those files should a change be seen, I copied the old job, but removed the "forbidden file path" and added a "file path" with the same mask.

    both projects had the change applied and saved.  We do have multiple branches, and can confirm that the branch where the change is being made is scanned by the gerrit trigger.

    Recently, someone changed a file in the doc directory, which triggered the original job and did not trigger the new job.

    What am I doing wrong?

  39. I struggled a whole bunch just getting the build triggers working and wanted to share what I discovered.

    Start at "Query and Trigger Gerrit Patches". In my case I was easily able to connect to Gerrit and see my patchsets, but no matter what I tried the trigger always resulted in "No jobs triggered for this event".

    It turns out their is a critical configuration section in the Jenkins project config immediately under the "Dynamic Trigger Configuration" checkbox. The UX is confusing and the section immediately below the "Dynamic Trigger Configuration" checkbox is "Gerrit Projects" - it is its own separate section, it does NOT belong to "Dynamic Trigger Configuration". You MUST configure a Gerrit Project here for the trigger to work.

  40. Hi, I'm facing an stupid problem but have no way to solve.

    My Jenkins didn't send verified and code-review tag to Gerrit after Build Over (either success ,unstable, or failed)

    I could not see verified tag & code review tag in Gerrit dashboard

    Gerrit could trigger Jenkins when I'm upload some changes to Gerrit

    But I check jenkins accout has the right to review through command line 

    such: "ssh -p 29418 jenkins@gerritHost gerrit review --code-review +2 --verified +1  PATCH SET"

    I had also filled "project" -> "Configuration" -> "Gerrit Trigger" -> verifiy and Code-review values (-2~+2 )

    and "Jenkins" -> "Gerrit Trigger" -> "Gerrit Server Edit" -> "Gerrit Reporting Values" -> verifiy and Code-review values (-2~+2 )

    Did I miss anything ?  thank you for your reply

    here is my jenkins &gerrit version

    Jenkin ver 1.643

    Gerrit ver 2.8.5

  41. Hi all!

    This might be a long shoot, but definitely a desperate one :)

    So, I have the following config : Jenkins 1.643 ; gerrit-trigger plugin 2.16.0 (I have tried with 2.13.0, 2.18.3 as well but the same), a sample job configured and when I try my job I'm getting the following errors:

    Feb 08, 2016 3:32:15 PM com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onTriggered
    INFO: Project [test01] triggered by Gerrit: [PatchsetCreated: Change-Id for #4980: I757556868f51ba2b3f9021331af0d2321e250c75 PatchSet: 1]
    Feb 08, 2016 3:32:15 PM com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.EventListener schedule
    INFO: Project test01 Build Scheduled: true By event: 4980/1
    Feb 08, 2016 3:32:20 PM hudson.triggers.SafeTimerTask run
    SEVERE: Timer task hudson.model.Queue$MaintainTask@760549c6 failed
    java.lang.NoSuchFieldError: id
    	at com.sonyericsson.hudson.plugins.gerrit.trigger.replication.ReplicationQueueTaskDispatcher.canRun(ReplicationQueueTaskDispatcher.java:126)
    	at hudson.model.Queue.isBuildBlocked(Queue.java:1196)
    	at hudson.model.Queue.maintain(Queue.java:1511)
    	at hudson.model.Queue$MaintainTask.doRun(Queue.java:2753)
    	at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:50)
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    	at java.lang.Thread.run(Thread.java:745)

    Also I followed the instructions in this wiki and I have configured a parameterized build but when I click on the "Build with parameter" nothing happens and nothing logged ....

    If anyone got an idea on this error I would thank for that!

    Cheers,

  42. I found bug. If you have more than one server, then only first is used. Could you please make double-check? Such behaviour works for latest versions at least.

    • Restart the connection using the Status icon in the Server Table shown below

    Is there a way to do this using a REST API or equivalent? We would like to reset the connection automatically on a daily basis.

    Thanks

  43. This plugin is not working anymore with gerrit version 2.14.4 ,Could you please check it asap. We need to do major upgrades in gerrit and this plugin need to work.

  44. I ran into a snag with the dynamic configuration URL in that there is no "credentials" property to go with it.  I'd like to update this plugin to accept an optional set of credentials for accessing that URL.  Does anyone here have experience accepting credentials from a Jenkins plugin and then using those to make HTTP requests (or have a reference plugin that I can look at)?

  45. our project encounter such situations:  project include repository A and repository B, a developer revise both repositories, but B revision depends A revision. Now the problem is then when B revision is be push to Gerrit, then an patchset event is triggering Project job, but verify CI cannot succeed, because A revision is not submmited to master branch.  Can this problem have some solution, except the work flow solution that A revision must be submmited to master first?

     

    1. If I want to revise this plugin to triggering patchset event with A revision and B revision parameters to run Project Job, can this idea is feasible?

  46. I was trying to use this plugin to auto-submit patches that have both Code-Review+2 and Verified+1.  My plan was to use the "comment-added" event and then issue the "gerrit review ... --submit" command if both Code-Review+2 and Verified+1 were set.  While this event is triggered for comments that humans make, it does not seem to be triggered for Jenkins-driven comments.  Thus, my job is never triggered when Jenkins submits "Verified+1".

    Is this done on purpose?

    1. Ah, it looks like this is built into the plugin (but with no explanation); it ignores the e-mail address of whatever user has been configured in Jenkins:

      gerritEventManager.setIgnoreEMail(name, config.getGerritEMail());
      1. Ooooh, I see, the e-mail address for Gerrit (in the settings) is specifically there as a comment filter.  Never mind; everything is fine (smile)

  47. We're having an issue with this plugin when dealing with merge commit and hoping someone might be able to help.

    Setup: Gerrit 2.10.4, Jenkins  1.651.3

    Issue:

    • 2 separate commits exist in Gerrit, both have the same parent commit. e.g. A is parent (previously submitted), B and C are children of this (yet to be submitted).
    • When merging commit B, Jenkins picks up the commit and build it successfully
    • When merging commit C, since it has the same parent and the other child has been merged, a merge commit is created, commit D (which includes changes from B and C). However Jenkins builds commit C, which doesn't contain changes from B

    One way we've found to resolve this is to choose a Choosing strategy of "Default" rather than "Gerrit Trigger" but that isn't consistent with the advice on this page.

    --------

    Current Jenkins config:

    ----------------

    Actual example of commits:

    The build still uses the wrong commit (e.g. 133898...).

     > git rev-parse 133898f087ea41a3b63cad47422cb9e469ac663b^{commit} # timeout=10
    Checking out Revision 133898f087ea41a3b63cad47422cb9e469ac663b (refs/changes/61/37061/1)
    

    From git log --graph we can see that it should use the merge commit (e.g. 8e379e...).

    git log --graph
    *   commit 8e379e9aa148a156ba72351fe9462c557eeda023 (HEAD -> team/ABC, origin/team/ABC)
    |\  Merge: 799f6236 133898f0
    | | Date:   Tue Apr 17 11:01:24 2018 +0100
    | |
    | |     Merge "NA Removed dummy1.txt." into team/ABC
    | |
    | * commit 133898f087ea41a3b63cad47422cb9e469ac663b
    | | Date:   Tue Apr 17 10:54:11 2018 +0100
    | |
    | |     NA Removed dummy1.txt.
    | |
    | |     Change-Id: Ifa989f0ee108d1bf0e18821ae3dbc05a131748be
    | |
    * | commit 799f62362433347a782ce4b704e7d4e8ab99edae  
    |/  Date:   Tue Apr 17 10:56:30 2018 +0100
    |
    |      NA Removed dummy2.txt.
    |
    |       Change-Id: I5e5a3971fce1709a9bbf33f5825df2ec786cee4c
    |

     

    ----------------

    Thanks!

  48. why the restored change wil not be scored? are there some special reasons?

  49. We added "recheck" comment at `Comment Added Contains Regular Expression ` to recheck our CI, but it can not automatically cancel the working job which is the same patch with recheck comment, then the job is reduplicated to work for the patch. How should we do ? 

    Thanks.