Gerrit Trigger

Skip to end of metadata
Go to start of metadata

This plugin integrates Jenkins to Gerrit code review for triggering builds when a "patch set" is created.

Plugin Information

Plugin ID gerrit-trigger Changes In Latest Release
Since Latest Release
Latest Release
Latest Release Date
Required Core
Dependencies
2.13.0 (archives)
Apr 24, 2015
1.565.3
rebuild (version:1.22, optional)
git-client (version:1.4.2, optional)
git (version:1.2.0, optional)
rabbitmq-consumer (version:2.2, optional)
Source Code
Issue Tracking
Pull Requests
Maintainer(s)
GitHub
Open Issues
Pull Requests
Robert Sandell (id: rsandell)
Tomas Westling (id: twestling)
Usage Installations 2014-May 2373
2014-Jun 2389
2014-Jul 2536
2014-Aug 2608
2014-Sep 2729
2014-Oct 2928
2014-Nov 2941
2014-Dec 2945
2015-Jan 3104
2015-Feb 3144
2015-Mar 3337
2015-Apr 3428

Set Up

Gerrit access rights

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

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

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

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

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

Administrative Settings

Specify the Gerrit server settings via "Manage Jenkins > Gerrit Trigger"

Fill in the server settings:

Click "Test Connection" to verify the connection.

When everything seems ok, save your settings and restart the connection in the "Control" section at the bottom of the page:

There are many more settings for your pleasure, look at the individual help sections for information what they are about.

Trigger Configuration

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

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

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

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


Comment added configuration.

Specify what Gerrit project(s) to trigger a build on.

At least one project and branch pattern needs to be specified for a build to be triggered,and you can specify as many gerrit project to trigger on as you want.

Start by specifying the name of the Gerrit project in the left hand text field.
You can specify the name pattern in three different ways, as provided by the "Type" drop-down menu.

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

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

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

Dynamic triggering

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

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

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

Explanation:

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

Branch and file lines are assumed to be part of the closest preceding project line.

The dynamic triggering can be used in combination with the usual configuration, described above. The gerrit trigger will

trigger both for the dynamic and non-dynamic configurations.

The interval on which Jenkins fetches the file is configurable in the administrative pages for the Gerrit trigger, under advanced:

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

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

     

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.

The search page will also not show the verdict of the patches until we've fixed that page, but it shouldn't hinder the functionality of that page.

Change Log

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

Version 2.13.0 (released Apr 24 2015)

2.13.0-beta-6 promoted to stable.

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

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

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

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

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

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

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

I Botched the beta-1 release.

Version 2.12.0 (released Nov 14 2014)

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

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

Final rc for 2.12

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

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

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

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

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

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

Features and Fixes

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

Bumped core dependency to 1.509.3

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

Version 2.11.1 (released Mar 21 2014)

Version 2.11.0 (released Jan 14 2014)

2.11.0-beta-4 promoted to "stable".

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

Last release for the year.

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

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

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

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

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

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

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

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

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

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

Version 2.10.1 (released June 17, 2013)

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

Version 2.10.0 (released May 30, 2013)

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

Version 2.9.0 (released Mar 12, 2013)

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

Version 2.8.0 (released Feb 21, 2013)

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

Version 2.7.0 (released Dec 5, 2012)

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

Version 2.6.0 (released Sep 19, 2012)

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

Version 2.5.2 (released May 7, 2012)

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

Version 2.5.1 (released Mar 13, 2012)

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

Version 2.5.0 (released Mar 8, 2012)

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

Version 2.4.0 (released Feb 17, 2012)

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

Version 2.3.1 (released Sep 14, 2011)

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

Version 2.3.0 (released Mar 31, 2011)

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

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

Version 2.2.0 (released Oct 7, 2010)

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

Version 2.1.0 (released July 26, 2010)

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

Version 2.0 (released July 5, 2010)

  • First release.

Labels

plugin-trigger plugin-trigger Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 17, 2010

    Matthias Sohn says:

    If the plugin triggers the build but doesn't choose the commit associated with t...

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

  2. Dec 19, 2010

    Joe Hansche says:

    The current configuration instructions will cause Hudson to pull the version of ...

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

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

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

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

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

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

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

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

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

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

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

    1. Jan 03, 2011

      Joe Hansche says:

      Realized that this extra shell script isn't necessary, if we configure the job a...

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

      1. Mar 23, 2011

        diwakergupta says:

        Joe, could you please share the details of your setup? I'd like to use the same ...

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

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

        Not quite sure whats going on there.

        1. Jul 16, 2011

          jhansche says:

          I'm not sure what would cause that – what happens if you login to the serv...

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

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

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

  3. Dec 29, 2010

    Joe Hansche says:

    For about a week now, we've been seeing some weird behavior where a single Gerri...

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

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

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

    1. Dec 29, 2010

      Joe Hansche says:

      Here's an example of the case where it shows 2 URLs -- the original URL ...

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

      1. Jun 06, 2011

        netguy204 says:

        I'm seeing a very similar behavior. In my case a single trigger executes the app...

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

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

        1. Jul 16, 2011

          jhansche says:

          FWIW, I ended up finding the culprit in our environment: we still had an older ...

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

  4. Apr 28, 2011

    docwhat says:

    I have a maven project and it has two jenkins jobs: A gerrit and non-gerrit buil...

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

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

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

  5. May 26, 2011

    larrycai says:

    In chapter "Usage with the Git Plugin", better to mention $GERRIT_REFSPEC will b...

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

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

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

  6. Jul 21, 2011

    pejeremy says:

    When loggin in the management pane I get the error "The connection to Gerrit is ...

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

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

    I know that gerrit is up and functioning.

  7. Jul 26, 2011

    teqvick says:

    We are using modules (with Ivy plugin) in our Jenkins job which is started with ...

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

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

  8. Aug 30, 2011

    rogerfour says:

    We are using this plugin for our CI.The problem I encounter is that I can only s...

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

    public jenkins Patch Set 1: Test Build Started … 9:36 AM
    public jenkins Patch Set 1: Test Build Started … 9:56 AM
    public jenkins Patch Set 1: Test Build Started … 9:58 AM
    public jenkins Patch Set 1: Test Build Started … 10:01 AM
    public jenkins Patch Set 1: Test Build Started … 10:32 AM

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

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

    Can you give me some suggestions?

    1. Sep 29, 2011

      Sven Oppermann says:

      Run into the same problem today. Took me some hours to find the "bug". Make sure...

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

      1. Oct 09, 2011

        rogerfour says:

        Yes,you are right.Thank you!

        Yes,you are right.Thank you!

  9. Nov 03, 2011

    baekseonguk says:

    I have a question about Jenkins's Gerrit Trigger.  Many gerrit processes ar...

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

    Many gerrit processes are running in machine. 

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

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

    Jenkins manage > Gerrit Trigger 

    Gerrit Server 

    Hostname 

    Frontend URL 

    SSH Port 

    Username 

    SSH Keyfile 

    SSH Keyfile Password 

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

    Please help.

    1. Nov 03, 2011

      Robert Sandell says:

      It is not possible to do today. The feature has been requested before and it wa...

      It is not possible to do today.

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

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

  10. Nov 17, 2011

    andrew_at_plextek says:

    I have a question regarding the "Query and Trigger Gerrit Patches" screen from t...

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

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

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

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

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

    Thanks, Andrew. 

    1. Jan 10, 2012

      Robert Sandell says:

      It sounds as if you have something wrongly configured, but at the same time if t...

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

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

  11. Nov 29, 2011

    rschulz says:

    It would be very nice to be able to append the number of warnings (from the Warn...

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

    1. Jan 03, 2012

      jhansche says:

      I agree it would be nice to be able to customize the approval comment in general...

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

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

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

      or:

      make all
      
      if [ $? -ne 0 ]; then
          echo "Failed to compile!" > gerrit-comment.txt
      fi
      
      1. Jan 10, 2012

        Robert Sandell says:

        That sounds like a simple enough feature, there is already a "custom message per...

        That sounds like a simple enough feature, there is already a "custom message per job" feature so adding this shouldn't be too hard.

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

        Anyone interested in developing it?

        1. Feb 21, 2012

          jhansche says:

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

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

    2. Jan 10, 2012

      Robert Sandell says:

      I've heard some rumor that Gerrit will get command line support for adding line ...

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

  12. Jan 10, 2012

    samhardy says:

    We've got the gerrit trigger plugin working well at verifying checkins - actuall...

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

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

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

    Thanks...

    1. Mar 07, 2012

      ntfreak says:

      Tried a few things to stop this aswell. In the end the 'hack' we use is to repla...

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

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

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

    2. Mar 07, 2012

      Robert Sandell says:

      A new option to the approve command came in to the Gerrit trunk the other day ca...

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

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

  13. Jan 11, 2012

    samhardy says:

    Going back to having a single job which is gerrit-triggered, so less noise in th...

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

  14. Feb 15, 2012

    Werner Beroux says:

    How to allow "Build Now" and "Retrigger" to work? Once setup for Gerrit the norm...

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

    1. Mar 07, 2012

      Robert Sandell says:

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

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

  15. Feb 28, 2012

    Patrick Renaud says:

    Have you considered adding support for multiple Gerrit servers? We are in that s...

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

    1. Mar 07, 2012

      Robert Sandell says:

      I had considered it. When I made the original design I did some preparation work...

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

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

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

      1. Mar 14, 2012

        Patrick Renaud says:

        OK, this is good news then. I am willing to put some time aside to do the work b...

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

  16. Mar 08, 2012

    sleekweasel says:

    I find I get the error: FATAL: Null value not allowed as an environment variabl...

    I find I get the error:

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

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

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

    Thanks.

    1. Mar 24, 2012

      ktyk says:

      I became the similar phenomenon, too. Our CI Ver, Jenkins ver. 1.451 + Git Plug...

      I became the similar phenomenon, too.

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

      The workarounds to a problem were as follows.

      * Choosing strategy = Default  

      1. Mar 25, 2012

        ktyk says:

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

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

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

        But as a small problem. . .

        Its cause

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

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

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

        git : Refspec $GERRIT_REFSPEC  (Win xp 32 :  "${GERRIT_REFSPEC}"  )
        Branches to build: Branch Specifier (blank for default):  $GERRIT_PATCHSET_REVISION or "origin/master | master" (Default is bad)
        Choosing strategy Gerrit Hudson Trigger
        Build Trigger Gerrit Event: Plain= repo-name ,  Path= **
  17. Mar 17, 2012

    bostonvaulter says:

    I'm getting a weird error. It says my version of Gerrit is a bit old (which is p...

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

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

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

    1. May 07, 2012

      Robert Sandell says:

      Fixed it in the latest release, thanks for noticing. When we designed the featu...

      Fixed it in the latest release, thanks for noticing.

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

  18. Apr 18, 2012

    samxiao says:

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

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

    1. May 07, 2012

      Robert Sandell says:

      It's in the works. Keep an eye on https://github.com/jenkinsci/gerrit-trig...

      It's in the works.

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

      1. Jun 04, 2012

        gjeudy says:

        We're trying to use git polling to workaround this missing feature, but its runn...

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

      2. Jun 04, 2012

        gjeudy says:

        We're trying to use git polling to workaround this missing feature, but its runn...

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

  19. May 02, 2012

    kavuri says:

    I am having a problem with the combination of Git + Gerrit + Ant build, specific...

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

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

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

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

    1. May 06, 2012

      kavuri says:

      I figured out the cause of problem. The name of the GERRIT user is sent without ...

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

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

      and

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

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

  20. May 30, 2012

    pickerweng says:

    I have a problem to use this plugin. Here is the System environment, Ubuntu 10...

    I have a problem to use this plugin.

    Here is the System environment,

    Ubuntu 10.04

    Jenkins LTS v1.447.1

    Git plugin v1.1.8, 

    Gerrit Trigger plugin v2.5.2

    Gerrit 2.3

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

    But I can't find out any solution.

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

    The following is my polling log, any help?

    --------

    Using strategy: Gerrit Trigger

    Fetching changes from 1 remote Git repository

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

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

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

    stdout: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1. May 30, 2012

      Robert Sandell says:

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

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

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

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

      1. May 31, 2012

        pickerweng says:

        Thanks for your reply! My purpose is the Gerrit Trigger can detect the new p...

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

  21. Jun 18, 2012

    chad3814 says:

    We have *almost* everything working with Gerrit-Trigger, Gerrit and Jenk...

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

    Platform:

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

    1. Jun 18, 2012

      chad3814 says:

      Figured it out, FYI for others who make the same mistake, make sure the user tha...

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

  22. Jul 11, 2012

    Ki Sung Bae says:

    Is there a way to build patches over multiple project together? I'm using repo ...

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

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

    ID Subject Owner Project Branch Updated V R
        I5e6af241 This fixes #844 gsong frameworks master      
        I43cf5ea3 This fixes #844 gsong MyApplication master      

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

  23. Jul 11, 2012

    Sven Oppermann says:

    Another Question. In a specific branch, jenkins should Verify, Review AND Submit...

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

    1. Aug 09, 2012

      Sven Oppermann says:

      Found a workaround. In the global configuration: replace     gerrit approve &l...

      Found a workaround. In the global configuration:

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

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

      1. Aug 09, 2012

        Matthias Sohn says:

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

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

        1. Aug 09, 2012

          Sven Oppermann says:

          you are right. corrected it.

          you are right. corrected it.

  24. Aug 30, 2012

    lfalberti says:

    I'd like to trigger a build when a change is accepted and merged in the Gerrit U...

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

    Thank you

    1. Aug 30, 2012

      Sven Oppermann says:

      why triggering it via gerrit? you could create a jenkins job, which "ask" the gi...

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

      1. Aug 31, 2012

        lfalberti says:

        Thank you for the suggestion, I did set it up with polling: I look at changeSet ...

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

    2. Aug 30, 2012

      Robert Sandell says:

      The next version (2.6.0) will provide the ability to trigger on "change merged",...

      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.

      1. Aug 31, 2012

        lfalberti says:

        Wonderful!

        Wonderful!

  25. Sep 18, 2012

    ingunawa says:

    I am trying to make Gerrit trigger to trigger build automatically but so far it ...

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

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

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

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

    ...

    I also see numerous lines of:

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

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

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

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

    Triggering Builds:  "No jobs triggered for this event"

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

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

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

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

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

    Thanks.
    -Indra

    1. Mar 05, 2013

      sorrison says:

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

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

      1. Mar 05, 2013

        Robert Sandell says:

        A standard mistake that people do when configuring "**" on branches is that they...

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

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

  26. Sep 20, 2012

    meggleton says:

    I'm having a problem with failing builds that are triggered: [JOBNAME] $ cmd.ex...

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

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

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

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

    Can anyone help?

    ANT 1.8.4

    Latest Gerrit Plugin and Jenkins version

    Windows 2008 Slave

    Thx

  27. Sep 21, 2012

    i077265 says:

    Hi, i have this problem: Started by user Lyubomira Valcheva Building remotely...

    Hi, i have this problem:

    Started by user Lyubomira Valcheva

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

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

    Using strategy: Default

    Cloning the remote Git repository

    Cloning repository origin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    stderr: Permission denied (publickey).

    fatal: The remote end hung up unexpectedly

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

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

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

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

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

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

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

                    ... 13 more

    Trying next repository

    ERROR: Could not clone repository

    FATAL: Could not clone

    hudson.plugins.git.GitException: Could not clone

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

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

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

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

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

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

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

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

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

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

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

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

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



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

    1. Sep 22, 2012

      ingunawa says:

      Have you registered the user account used only for build on Gerrit?  Have y...

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

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

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

      -Indra

      1. Sep 24, 2012

        i077265 says:

        O.k. I put the name but there is another error: d:\jenkins\workspace\DONE Chec...

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

        d:\jenkins\workspace\DONE

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

        Using strategy: Default

        Cloning the remote Git repository

        Cloning repository origin

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

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

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

        stdout:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        ERROR: Could not fetch from any repository

        FATAL: Could not fetch from any repository

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  28. Oct 23, 2012

    adia20092009 says:

    I found that our job configuration is often changed automatically. Our original ...

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

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

    1. Jan 29, 2013

      Robert Sandell says:

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

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

  29. Jan 29, 2013

    xecle says:

    I want to post additional message to gerrit when vote. I set the Gerrit verify c...

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

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

    1. Jan 29, 2013

      Robert Sandell says:

      export is only valid for the process that it is made in and any sub processes, s...

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

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

      1. Jan 30, 2013

        xecle says:

        Thanks, I get it. Maybe additional message for successful builds is not needed, ...

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

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

  30. May 23, 2013

    danielhwang says:

    In Query and Trigger Gerrit patches of Jenkins, when i add query string then I f...

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

    Unknown macro: {"name"}

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

    Unknown macro: {"name"}

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

    Unknown macro: {"name"}

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

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

    1. May 23, 2013

      ktyk says:

      I think you tag designated and put in place can downgrade. https://github.com/j...

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

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

      You can upload from the Plugin Manager for Jenkins.

      1. May 24, 2013

        danielhwang says:

         I downloaded gerrit-trigger-plugin-gerrit-trigger-2.5.0.zip file from...

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

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

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

        1. May 25, 2013

          ktyk says:

          Sorry for the late reply. I was able to create hpi file. Have not tried is jus...

          Sorry for the late reply.

          I was able to create hpi file.

          Have not tried is just below.

          • Ver2.5
          • verified to work

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

          1. Clone from Github
          2. Version changes in the position of the tag (I think that even a zip file is the same.)
            e.g.) Use of git tag
            $ git tag -ln | grep 2.5

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

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

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

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

          I hope the best for you.

      2. May 27, 2013

        Robert Sandell says:

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

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

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

    2. May 27, 2013

      Robert Sandell says:

      There are no correlations between the versions of Gerrit and the Jenkins Gerrit ...

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

    3. Jun 03, 2013

      danielhwang says:

      In this problem, Only 'KOREAN' word is broken. Is it encoding problem? How can ...

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

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

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

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

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

  31. Jul 22, 2013

    scooper4711 says:

    I'm experimenting with Gerrit, and I am unsure how to do something, or even if I...

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

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

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

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

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

  32. Sep 09, 2013

    tdxmgy says:

    HI I found Gerrit Trigger plugin alaways  trigger one build on  two bu...

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

  33. Dec 16, 2013

    maxximillian says:

    I'm sorry if this is a plainly obvious question but for the "build now" tip to s...

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

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

    where exactly does one add this?

  34. Jan 13, 2014

    vladichko says:

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

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

  35. Aug 22, 2014

    jrawlings says:

    If you are having issues sending any review comments to Gerrit, after investigat...

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

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

    Steps in Jenkins..

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

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

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

    to

    gerrit review <CHANGE>,<PATCHSET> --message 'Build Started <BUILDURL> <STARTED_STATS>' --code-review <CODE_REVIEW>
  36. Sep 15, 2014

    polarice says:

  37. Jan 01

    alexei says:

    Hi, the Gerrit Trigger plugin allows you to create multiple jobs with ...

    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 ?

  38. Jan 04

    alexei says:

    I want to trigger job only when specific reviewer is added,  this option no...

    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 ?

  39. Feb 11

    jonbridgstock says:

    I'm having a bit of a problem - recently modified a working CI build to get it t...

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

    **/doc/**
    

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

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

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

    What am I doing wrong?

  40. Apr 07

    gkopley says:

    I struggled a whole bunch just getting the build triggers working and wanted to ...

    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.