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

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

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

Dynamic triggering

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

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

Usage with the Git Plugin

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

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

Usage with Repo

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

Verifying functionality

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

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

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

Skip Vote

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

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

Additional Screenshots

Pipeline Jobs

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

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

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

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

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

Tips & Tricks

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

Using "Build Now"

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

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

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

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

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

Note to Gerrit > 2.6 Users

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

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

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

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

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

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

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

Version 2.23.0 (released Nov 25 2016)

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

Version 2.18.1 (released Dec 3 2015)

Version 2.18.0 (released Dec 1 2015)

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

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

Version 2.17.2 (released Oct 29 2015)

Version 2.17.1 (released Oct 28 2015)

Version 2.17.0 (released Oct 26 2015)

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

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

Version 2.0 (released July 5, 2010)

104 Comments

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:

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:

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

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.

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)

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.

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.

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.

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.

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?

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

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?

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?

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.

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:

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.

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.

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.

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

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.

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.

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.

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.

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?

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?

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

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?

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.

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?

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

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.

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.

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 ?

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 ?

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.

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.

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":

,"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?

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?

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

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.

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.

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:

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)?

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？

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

2 separate commits exist in Gerrit, both have the same parent commit. e.g. A is parent (previously submitted), B and C are children of this (yet to be submitted).

When merging commit B, Jenkins picks up the commit and build it successfully

When merging commit C, since it has the same parent and the other child has been merged, a merge commit is created, commit D (which includes changes from B and C). However Jenkins builds commit C, which doesn't contain changes from B

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

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 ?

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?