Gerrit Trigger

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

Plugin Information

Plugin ID gerrit-trigger
Latest Release 2.5.3-h-1
Latest Release Date Oct 22, 2012
Sources Github
Support Eclipse Hudson Forum
Issue Tracking Eclipse Bugzilla

Source Code

The source code is available on GitHub .

Configuration

Administrative Settings

Specify the Gerrit server settings via "Manage Hudson > Gerrit Hudson 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 Gerrit project(s) to trigger a build on.

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

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

  • Plain: The exact name in Gerrit, case sensitive equality.
  • Path: ANT style pattern. Ex: "*/base/**"
  • RegExp: Regular expression.

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

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

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

Additional Screenshots

     

Change Log

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
  • HUDSON-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
  • HUDSON-6967 Missing default parameters.
  • HUDSON-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:
Wait Image 
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.

  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.