Configuring Gerrit and Jenkins to work in harmony.

[Brian Troutwine]

Hello, all.

Please forgive the cross-list posting. I am unsure whether I have a
Jenkins issue or a Gerrit issue; for reference I am using 1.430 of the
former and 2.2.1 of the latter. My problem is this: when I push
patches into a Gerrit managed refs/for/master no build is sparked in
Jenkins, though I have followed the configuration guide for 'Gerrit
Trigger' here:

https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger

On Jenkins' end the connection test in the Gerrit Triggers
configuration succeeds and from the box hosting Jenkins I can got a
clone of the Gerrit controlled repository. When I try a manual build
of the project--via the Build Now of the left sidebar--I get the
following in the console:

Started by user Brian L. Troutwine
Checkout:workspace /
/var/lib/jenkins/jobs/carepilot-admin-stable/workspace -
hudson.remoting.LocalChannel@53a928f9
Using strategy: Gerrit Trigger
Checkout:workspace /
/var/lib/jenkins/jobs/carepilot-admin-stable/workspace -
hudson.remoting.LocalChannel@53a928f9
Fetching changes from 1 remote Git repository
Fetching upstream changes from
ssh://rev...@review.carepilot.com:29418/admin.git
ERROR: Problem fetching from origin / origin - could be
unavailable. Continuing anyway
ERROR: (Underlying report) : Error performing command: git fetch
-t ssh://rev...@review.carepilot.com:29418/admin.git $GERRIT_REFSPEC
Command "git fetch -t
ssh://rev...@review.carepilot.com:29418/admin.git $GERRIT_REFSPEC"
returned status code 128: fatal: Couldn't find remote ref
$GERRIT_REFSPEC

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:1008)
at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:968)
at hudson.FilePath.act(FilePath.java:758)
at hudson.FilePath.act(FilePath.java:740)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:968)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1193)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:566)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:454)
at hudson.model.Run.run(Run.java:1376)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:230)

I'm happy to share more configuration and/or screenshots, but I'm not
sure what would be apropos.

Thanks,

--
Brian L. Troutwine

[Alex Blewitt]

You can't do a "build now" on a Jenkins build with a gerrit refspec. You'll need to create a second build for that.

Check that the daemon is started for the gerrit trigger, and check in the logs that it is running. You should be able to do a verify on the password.

I wrote how to set this up for InfoQ at http://www.infoq.com/articles/Gerrit-jenkins-hudson

Alex

Sent from my (old) iPhone

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

[Brian Troutwine]

On Thu, Sep 15, 2011 at 4:50 PM, Alex Blewitt <alex.b...@gmail.com> wrote:
> You can't do a "build now" on a Jenkins build with a gerrit refspec. You'll need to create a second build for that.

Good to know.

> Check that the daemon is started for the gerrit trigger, and check in the logs that it is running.

Here's what happened after restarting the Gerrit Trigger daemon:

Sep 15, 2011 9:05:24 PM
com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler
shutdown
INFO: Shutting down the ssh connection.
Sep 15, 2011 9:05:24 PM
com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Starting Up...
Sep 15, 2011 9:05:25 PM
com.sonyericsson.hudson.plugins.gerrit.gerritevents.GerritHandler run
INFO: Ready to receive data from Gerrit

> You should be able to do a verify on the password.

Mashing "Test Connection" in the same configuration panel

Sep 15, 2011 9:07:14 PM
com.sshtools.j2ssh.transport.publickey.SshPrivateKeyFile parse
INFO: Parsing private key file
Sep 15, 2011 9:07:14 PM
com.sshtools.j2ssh.transport.publickey.SshPrivateKeyFile parse
INFO: Private key is not in the default format, attempting parse
with other supported formats

It's worth noting that the key is straight out of ssh-keygen.

> I wrote how to set this up for InfoQ at http://www.infoq.com/articles/Gerrit-jenkins-hudson

Following along at the bottom of the article when I do an is:open
query and I trigger selected all I have as a result is a message on
the left-hand side saying "No jobs triggered for this event".

--
Brian L. Troutwine

[Alex Blewitt]

On 15 Sep 2011, at 22:16, Brian Troutwine <briantr...@carepilot.com> wrote:

It's worth noting that the key is straight out of ssh-keygen.

I've found Gerrit to be fussy about the type of ssh keys depending on version of openssh. I have seen v4 keys fail and v5 keys work. 

If it's making a connection though then so far so good. 

I wrote how to set this up for InfoQ at http://www.infoq.com/articles/Gerrit-jenkins-hudson

Following along at the bottom of the article when I do an is:open
query and I trigger selected all I have as a result is a message on
the left-hand side saying "No jobs triggered for this event".

Have you configured the path/project regexp/path? This is an easy step to miss, and without it, Jenkins doesn't know which project to build when a random Gerrit change comes in. I think the article talks about changing it to path and **. 

As a blatant plug, I'm doing a talk on Gerrit for the London Java Community on 20th October at Skillsmatter; I suspect the event may be video'd and made available subsequently for those that aren't local. 

Alex

[Brian Troutwine]

On Thu, Sep 15, 2011 at 6:38 PM, Alex Blewitt <alex.b...@gmail.com> wrote:
> Have you configured the path/project regexp/path? This is an easy step to
> miss, and without it, Jenkins doesn't know which project to build when a
> random Gerrit change comes in. I think the article talks about changing it
> to path and **.

I didn't miss that, I'm afraid. I have, specifically, 'admin' and '**'
in the pattern and branches slot, respectively.

> As a blatant plug, I'm doing a talk on Gerrit for the London Java Community
> on 20th October at Skillsmatter; I suspect the event may be video'd and made
> available subsequently for those that aren't local.
> Alex

I'd like to see that talk.

--
Brian L. Troutwine

[Alex Blewitt]

On 16 Sep 2011, at 00:06, Brian Troutwine <briantr...@carepilot.com> wrote:

n Thu, Sep 15, 2011 at 6:38 PM, Alex Blewitt <alex.b...@gmail.com> wrote:

Have you configured the path/project regexp/path? This is an easy step to

miss, and without it, Jenkins doesn't know which project to build when a

random Gerrit change comes in. I think the article talks about changing it

to path and **.

I didn't miss that, I'm afraid. I have, specifically, 'admin' and '**'
in the pattern and branches slot, respectively.

This is from the doc on the plugin:
---

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

---

Is it possible that the repository name is different? Maybe the case? You could verify by replacing with a ** for the project to check. 

Alex

[Brian Troutwine]

On Fri, Sep 16, 2011 at 12:17 PM, Alex Blewitt <alex.b...@gmail.com> wrote:
> On 16 Sep 2011, at 17:00, Brian Troutwine wrote:
>
>> On Fri, Sep 16, 2011 at 11:04 AM, Alex Blewitt <alex.b...@gmail.com> wrote:
>>>
>>> On 16 Sep 2011, at 15:37, Brian Troutwine wrote:

>>>
>>>> On Thu, Sep 15, 2011 at 7:28 PM, Alex Blewitt <alex.b...@gmail.com> wrote:
>>>>> Is it possible that the repository name is different? Maybe the case?
>>>>

>>>> No, it is distinctly 'admin' in both Gerrit; I have confirmed from the
>>>> UI and by peeking into Gerrit's home directory.

>>>>
>>>>> You could verify by replacing with a ** for the project to check.
>>>>

>>>> Having changed both values to '**' I find that there is no difference
>>>> in behavior.
>>>
>>> And the 'type' is 'path' for both of them?
>>
>> That was it! I had it set to 'plain', not understanding that 'Path' in
>> everything I've been reading was a configurable value I should have
>> set.
>
> Great. Note that once you have it operational, you'll probably want to put it to something like 'plain' and make it explicit for your project - otherwise, it'll build for everything. You might need to experiment with the project name though, for example, putting 'admin.git' or - if there's a subdirectory - something like 'gits/admin.git'

I've found that it's sufficient to have Path 'admin', Plain
'admin.git'. Interestingly, when set to 'Plain' I am given an
temporary drop-down of suggested values, which include 'admin', but
which are not valid. It is also the case that I had to explicitly set
the build branch, changing it from **, as otherwise I received a Null
branch exception in the git handling code.

> I think plain does an exact match and path allows you to use * for a wildcard excluding directories and ** including directories, so ** matches /a/b/c but * will only match a
>
> Happy gerriting!

Thank you very much for your help!

> Alex
>
> PS you might want to forward the solution to the list so that they know the resolution as del

Quite so; I hadn't realized I'd dropped everyone out.

--
Brian L. Troutwine