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
- Create the profile through in Gerrit web interface for your Jenkins user, and set up a SSH key for that user.
- Gerrit web interface > Admin > Groups > Non-Interactive Users > Add your jenkins user.
- 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
- Reference:
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.
- Gerrit web interface > People > Create New Group : "Event Streaming Users". Add your jenkins user.
- Admin > Projects > All-Projects > Access > Edit
- Global Capabilities
- Stream Events: ALLOW for Event Streaming Users
- Global Capabilities
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.
- Path: ANT style pattern. Ex: "*/base/**"
- RegExp: Regular expression.
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:
- The REST api to be configured for the Gerrit Server Connection.
- The Gerrit Events-log plugin must be installed on the Gerrit Server (Please see https://gerrit.googlesource.com/plugins/events-log/)
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.
- Please see https://gerrit.googlesource.com/plugins/events-log/ for installation details.
Verifying functionality
- Once you have restarted the connection, click on the Edit icon in the Server Table. If there is a problem with the Playback Manager's configuration, you will see this:
- If the Playback Manager is correctly setup, you will see the following in the Jenkins log file when the Gerrit Server Connection is started:
INFO: (8) missed events to process for server: defaultServer ...
Skip Vote
"Skipping" the vote means that if more than one build is triggered by a Gerrit event the outcome of this build that "skips its vote" won't be counted when the final vote is sent to Gerrit. If this is the only build that is triggered then the vote will be 0.
This can be useful if you have one job that triggers on all patch set created events that just checks that the commit message is correctly formatted, so it should only deny merging if it is a bad commit message but also not allow the merge just because the message was ok. In that scenario you could configure the "check commit message" job to skip voting on Successful.
Additional Screenshots
Pipeline Jobs
Version 2.15.0 of the Gerrit Trigger plugin supports Jenkins Pipeline job types. So as with the traditional job types, this plugin supports:
- Triggering of Pipeline Jobs based on Gerrit Event notifications e.g. the Patchset Created event.
- Checkout of the change-set revision from the Gerrit Git repository. See example below.
- 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:
- Go to "Manage Jenkins" and click the "Gerrit Trigger" link
- Under "Gerrit Servers" next to your server(s) click the "Edit" button (looks like a gear, other icons may overlap it)
- Under "Gerrit Reporting Values" click the Advanced button at the bottom
- Under "Gerrit Verified Commands" remove the '--verified <VERIFIED>' sections from each command, see screenshot
As of version 2.17.0 the verified "vote" is not sent at all to Gerrit (removed from the command line/rest call) unless there is an actual value to be sent. So if you change the configuration to contain only values for code review and empty strings for verified you won't get the error.
Change Log
Version 2.30.0 (released Aug 02 2019)
- JENKINS-54509 - Add check description is null then set description to "" (#399)
- EventFilter - Add capability to modify which events are interesting (#397)
- PlaybackManager - Persist to XML in a thread (#398)
Version 2.29.0 (released Feb 15 2019)
- Java 8 and Jenkins 1.121 (#389, #390)
- Support triggering for wip-state-changed and private-state-changed (#383)
- Start the trigger in a known state when using a dynamic configuration URL (#350)
- JENKINS-55262 - Missing content-type on serverStatuses REST API (#388)
Version 2.28.0 (released Dec 19 2018)
- Make filtering out gerrit user's comments configurable (#384)
- Clean up some eclipse warnings (#386)
- Fix the synchronisation block in gerritEvent() (#382)
- Fix problem with static access to SimpleDateFormat (#381)
- skip updating the dynamic configuration if jobs are disabled (#380)
- Update documentation to link to latest major Gerrit release (#379)
- Improve logging in GerritPluginChecker (#378)
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-39498Getting issue details... STATUS Stop panicking about "eventCreatedOn" and losing my position (#346)
- - JENKINS-48622Getting 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)
- JENKINS-48943 Whitelist gerrit-events and workaround missing collections whitelisting in core for Jenkins 2.102+ (93a7719, pull #343)
- Fix loose forbidden file (pull #339)
Version 2.27.1 (released Dec 06 2017)
- Fixed JENKINS-39498 (pull #335)
- Fixed JENKINS-48155 (pull #336)
- Reduce memory usage (pull #337)
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)
Abort ongoing builds of topic if new change to the same topic was submitted (pull #326, #328)
- Fixed a ConcurrentModificationException in TriggerContextConverter (pull #327)
- Fixed JENKINS-20808 (pull #307)
- Fixed link to the job in memory report (pull #329)
- JENKINS-39132 No comments to Gerrit 2.13.1 for Change Merged trigger (pull #330)
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)
- Support sending multi-line comments (pull #316)
- JENKINS-45095 Fix (pull #320)
- Added extra help text for regular expression matching (pull #321)
- JENKINS-44568, JENKINS-44414 Fix (g-e pull #68, pull #67)
Version 2.24.0 (released Jul 3 2017)
JENKINS-43904 Set tag for review comments on REST (pull #317)
Fixed some logging in GerritDynamicUrlProcessor (pull #315)
Version 2.23.3 (released Jun 9 2017)
- JENKINS-39010 Interpret the incoming comment message as multi-line text (pull #312)
- JENKINS-40965 Get out of gerrit event stream loop in illegal state (g-e pull #62)
- JENKINS-38542 NPE when canceling a task when no job (pull #314)
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)
- JENKINS-36139 Adapt Git BuildChooser to JGit4, introduced in Git Plugin 3.0.0-beta1 (pull #291)
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)
- JENKINS-34753 - Provide safe parameters to ParametersAction to fix regression from SECURITY-170, requires Jenkins >= 2.6 or equivalent (pull #285)
- JENKINS-23873 - Provide GERRIT_MERGED_REVISION after change-merged event (pull #284)
- Changed to new plugin parent pom structure (pull #281)
- Set Notification level on the build started trigger as well to silence some of the output (pull #282)
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)
- Partial JENKINS-26103 Pipeline step to customise the post back data. (pull #274)
- Guard against potential crash on core versions where JENKINS-33467 is fixed, i.e. >= 1.653 (pull #274)
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)
- JENKINS-31800 Fixed projectListRefreshInterval zero value after upgrade from 2.13.0 to 2.14.0. (pull #273)
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)
- JENKINS-31858 Fixed "Enable project Auto Completion" checkbox save. (pull #268)
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)
- JENKINS-30370 Fixed Config Page Auth validation (pull #263)
- Limit maximum tryLoadProjectList wait time to 64 seconds (pull #264)
Version 2.17.4 (released Nov 27 2015)
- JENKINS-31473 Project list is not updating in desired interval (pull #260)
- JENKINS-30975 Protect PlaybackManager from null EventCreatedOn (pull #261)
- JENKINS-31781 build completed for RefUpdated events with REST (pull #262)
Version 2.17.3 (released Nov 26 2015)
- JENKINS-31439 Correct Missed Events Playback manager initialisation (pull #259)
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)
- JENKINS-31199 Fix for REST API Build Completed with Locked Down instance (pull #256)
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)
- JENKINS-30620 Option to permit disable Strict Forbidden files (pull #252)
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)
- Some Code clean-up (pull #242, pull #243, pull #244, pull #245, pull #246, pull #248)
- Added Backwards compatibility tests for updated RefUpdated event in Gerrit 2.12 (pull #249)
- JENKINS-12690 Fix Issue with AES pass phrase encryption of keys (pull #250)
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)
- JENKINS-26010 Added support for triggering Workflow Jobs. (pull #240)
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)
- Correct Typo in Messages for Playback Warning (pull #237)
- JENKINS-28583 Improve backwards compatibility of Project Lister (pull #239)
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)
- Fixed the BRANCH build parameter and added TOPIC (pull #205)
- Always trigger upon manually triggered build (pull #216)
- Support configuration of when and how the project list for auto completion is fetched (pull #220, pull #225)
- Added incremental update of project list for users of Gerrit 2.12 (pull #227)
- Cleaned up some code (pull #207, pull #221, pull #222, pull #223, pull #232)
- Fix for "Build Current Patches Only" (pull #215)
- Workaround for JENKINS-17116 (pull #224)
- Superficial fix for JENKINS-28161 (pull #226)
- JENKINS-23871 Removed Unreviewed Patches feature in favour of Missed Events Playback on re-connect (pull #213, pull #228, pull #229)
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)
- JENKINS-27651 Rename issue. (pull #218)
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)
- Another regression from JENKINS-23152 fix; Gerrit notifier threads should impersonate SYSTEM (pull #202)
- Regression from previous Base64EncodedString parameter fix (pull #203)
- Updated com.jcraft.jsch to 0.1.51 (gerrit-events pull #32)
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.
- Silent Start (Commit #a50dbd5)
- JENKINS-23152 Reload fixes. (pull #193)
- Build completed message builds sorted worse first. (pull #192)
- JENKINS-26323 Fix "Build Current Patches Only" by scanning for event. (pull #195)
- Removed unnecessary select server description. (pull #196)
- Findbugs: null pointer dereference fixes. (pull #197)
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
- JENKINS-24445 Don't trigger builds triggered by the same event (pull #172)
- JENKINS-24575 Don't keep Extension instances (pull #175)
- JENKINS-19013 Fix session management in manual trigger page (pull #176)
- Provide notification level to gerrit command (pull #177)
- JENKINS-24295 Add one-off executor to search list for cancel job (pull #178)
- Fix topic rule for empty topic (pull #179)
- JENKINS-21407 Change manual trigger button to floating button (pull #180)
- JENKINS-21064 Include the latest patchset only in manual trigger page (pull #182)
- JENKINS-21064 Only send selected change data back to the server (pull #183)
- Use newRev for building on RefUpdated event (pull #184)
- JENKINS-25047 Fix DraftPublished and ChangeMerged -> Replication (pull #185)
- JENKINS-25047 Reschedule inflight pushes and help improvements for draft published (pull #188)
- Add support for remote API (pull #186)
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
- Lowered logging level when builds are completed (pull #147)
- JENKINS-22813 Git plugin is now optional in practice (pull #148)
- JENKINS-22814 Lowered a startup log message (pull #149)
- Support for receiving Gerrit events from RabbitMQ via RabbitMQ Consumer Plugin (pull #151)
- Fix for non negative replication cache timeout (pull #150)
- Support for review notification levels (pull #152)
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)
- Fixed JENKINS-22155
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.
104 Comments
Unknown User (msohn)
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).
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:
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:
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.:
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).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.
Unknown User (diwakergupta)
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:
Not quite sure whats going on there.
Unknown User (jhansche)
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.
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?
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.

Unknown User (netguy204)
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.
Unknown User (jhansche)
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.
Unknown User (docwhat)
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.
Unknown User (larrycai)
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"
Unknown User (pejeremy)
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.
Unknown User (teqvick)
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?
Unknown User (rogerfour)
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?
Unknown User (cecom)
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.
Unknown User (rogerfour)
Yes,you are right.Thank you!
Unknown User (baekseonguk)
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.
Unknown User (rsandell)
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.
Unknown User (andrew_at_plextek)
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.
Unknown User (rsandell)
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.
Unknown User (rschulz)
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?
Unknown User (jhansche)
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:
or:
Unknown User (rsandell)
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?
Unknown User (jhansche)
Shouldn't be hard to implement.. I'll try to get to it this week.
Unknown User (rsandell)
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.
Unknown User (samhardy)
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...
Unknown User (ntfreak)
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.
Unknown User (rsandell)
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.
Unknown User (samhardy)
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...
Unknown User (wernight)
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.
Unknown User (rsandell)
Added a "Tips and Tricks" section above where I describe how to solve this.
Unknown User (prenaud76)
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.
Unknown User (rsandell)
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.
Unknown User (prenaud76)
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.
Unknown User (sleekweasel)
I find I get the error:
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.
Unknown User (ktyk)
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
Unknown User (ktyk)
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= **
Unknown User (bostonvaulter)
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.
Unknown User (rsandell)
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.
Unknown User (samxiao)
How did you set it so it only builds on merged commit instead of status:open changes?
Unknown User (rsandell)
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.
Unknown User (gjeudy)
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?
Unknown User (gjeudy)
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?
Unknown User (kavuri)
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?
Unknown User (kavuri)
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.
Unknown User (pickerweng)
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)
Unknown User (rsandell)
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.
Unknown User (pickerweng)
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: * * * * *
Unknown User (chad3814)
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
Unknown User (chad3814)
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!
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.
Unknown User (cecom)
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?
Unknown User (cecom)
Found a workaround. In the global configuration:
In the job, where you want to submit via jenkins. Inject the environment variable "GERRIT_SUBMIT_ENTRY" with Value "--submit".
Unknown User (msohn)
looks like a typo: s/$GERRIT_SUMMIT_ENTRY/$GERRIT_SUBMIT_ENTRY/
Unknown User (cecom)
you are right. corrected it.
Unknown User (lfalberti)
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
Unknown User (cecom)
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.
Unknown User (lfalberti)
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.
Unknown User (rsandell)
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.
Unknown User (lfalberti)
Wonderful!
Unknown User (ingunawa)
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
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
Unknown User (sorrison)
I have exactly the same issue. Did you manage to resolve this?
Unknown User (rsandell)
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.
Unknown User (meggleton)
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
Unknown User (i077265)
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!
Unknown User (ingunawa)
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
Unknown User (i077265)
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)
Unknown User (adia20092009)
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 ?
Unknown User (rsandell)
Others seems to have had this as well, there is a Jira issue reported on it.
Unknown User (xecle)
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 ?
Unknown User (rsandell)
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.
Unknown User (xecle)
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.
Unknown User (danielhwang)
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":
,"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":
,"createdOn":1369118470},"patchSets":[{"number":"1","revision":"9eff9d5a1fc40d2dc8b41fc3519fdd705463530e","ref":"refs/changes/67/167/1","uploader":
,"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?
Unknown User (ktyk)
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.
Unknown User (danielhwang)
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?
Unknown User (ktyk)
Sorry for the late reply.
I was able to create hpi file.
Have not tried is just below.
FYI ) I have build hpi steps (a little fit 2.5)
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
Build run https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
I hope the best for you.
Unknown User (rsandell)
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/
Unknown User (rsandell)
There are no correlations between the versions of Gerrit and the Jenkins Gerrit Trigger plugin, they are two separate projects maintained by different people.
Unknown User (danielhwang)
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?
Unknown User (scooper4711)
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?
Unknown User (tdxmgy)
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
Unknown User (maxximillian)
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?
Unknown User (vladichko)
Hi all! any news/feedback on 2.11.0-beta-4 ?
Unknown User (jrawlings)
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..
to
Unknown User (polarice)
Unknown User (alexei)
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 ?
Unknown User (alexei)
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 ?
Unknown User (jonbridgstock)
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
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?
Unknown User (gkopley)
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.
Unknown User (kkbomb)
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
Unknown User (enexis)
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:
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,
Unknown User (maxx)
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.
Unknown User (chantivlad)
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
Unknown User (sakshisood)
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.
Unknown User (tekkamanendless)
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)?
Unknown User (fanqingsong)
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?
Unknown User (fanqingsong)
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?
Unknown User (tekkamanendless)
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?
Unknown User (tekkamanendless)
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());
Unknown User (tekkamanendless)
Ooooh, I see, the e-mail address for Gerrit (in the settings) is specifically there as a comment filter. Never mind; everything is fine
Unknown User (jgraham0325)
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:
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...).
From git log --graph we can see that it should use the merge commit (e.g. 8e379e...).
----------------
Thanks!
Unknown User (superliu)
why the restored change wil not be scored? are there some special reasons?
Unknown User (chenhb)
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.
Unknown User (lgrealis)
We've got a Jenkins build server in a different country (and hence timezone) to the Gerrit server. When Jenkins goes down and is bought back up, the events are not playing back.
I was looking at the bit of the code here:
gerrit-trigger-plugin/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/playback/GerritMissedEventsPlaybackManager.java):
I also had a look at the Gerrit events-log plugin code to see if any UTC type conversion was done. Not seeing anything, I was (maybe naively) expecting to see something like "df.SetTimeZone(TimeZone.getTimeZone("UTC"));"
As far as I can understand, this doesn't seem to do anything with the local datetime it obtains from the server. I've read about the improvements in Java8 java.time packages but the code seems to be using the java.util.Date package.
So, my initial conclusion was that a timezone difference between Gerrit/Jenkins servers won't be handled as is - can anyone confirm (or deny) that might be the issue I'm experiencing?
Thanks
Leigh