[Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Luca Milanesio]

Hi Gerrit and Jenkins Community,

after over two years of iterations and improvements of the Gerrit CI workflow (https://gerrit-ci.gerritforge.com), I have decided that is about time to extract the logic of our workflow and make it available as a brand-new Jenkins plugin!

Why?

I wanted to use the Gerrit CI validation workflow with potentially any project, including Gerrit plugins or anybody else wanting to adopt it.

I could just "copy & paste" our Groovy workflow, however, that does not seem a sensible and long-term approach.

I wanted to have "something more" than a pure triggering mechanism: I wanted to extend the power of Jenkisfile with the Gerrit review workflow verbs.

Why not?

Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit Trigger Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger) enough?

We couldn't use it against gerrit-review.googlesource.com because stream events are just not accessible.

There are unresolved issues about:

- Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

- Usability: at every JenkinsWorld conference people still come to me asking "how do I setup correct the Gerrit Trigger plugin"?

- Integration: using it inside a JenkinsFile isn't that straightforward and multi-branch projects aren't supported either

What would it be?

I will publish a new plugin named "Gerrit Pipeline Plugin."

The new name indicates:

- Deep integration with Jenkins Pipeline

- Out-of-the-box integration with Gerrit validation workflow in the pipeline

A simple example scripted Jenkinsfile would be:

node {
    checkout scm

    gerrit.withServer("http://gerrit:8080/", "gerrit") {

        try {
            docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
                stage('Build') {
                    sh 'sbt compile'
                }
                stage('Test') {
                    sh 'sbt 'test'
                }
            }

            gerrit.review("Verified", 1, "It works !")
        } catch (e) {
            gerrit.review("Verified", -1, "Breaks the build ;-(")
            throw e
        }
    }
}

(Where:

- https://gerrit-review.example.com would be the Gerrit URL

- mycredentialsid would be the id of the credentials to access Gerrit)

One key-aspect will be: stateless, configuration-less (apart from the credentials stored in Jenkins keychain)

That means that multiple Jobs, multiple branches of the same Job, can have their own Gerrit integration defined and working out-of-the-box.

No more people asking "how do I configure the Gerrit integration"?

You'll just define a gerrit.withServer() { } and ... it will just work.

When?

I am planning to showcase the first prototype of the new plugin at the Jenkins World Conference in San Francisco inside my "Data-Driven Pipeline workshop."

(https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free)

Shortly afterward, I will publish the plugin on the GerritForge's GitHub account and will start the integration process into the Jenkins CI organization.

Next steps?

A second iteration of the plugin would have a Declarative pipeline equivalent as well, which would require even less code required.

A third iteration of the plugin would support BlueOcean as well, to have a fully UX-integrated experience.

The goal is to have Gerrit Code Review to be a 1st class citizen in the Jenkins ecosystem :-)

So what happens to the Gerrit Trigger Plugin?

The new plugin is not going to replace the current Gerrit Trigger Plugin, but would rather represent an alternative to simpler scenarios when you just require a standard Jenkinsfile Gerrit validation workflow. For all the current users of the Gerrit Trigger Plugin things wouldn't change, unless they need a more Jenkisfile-integrated experience.

Feedback? Like it? Hate it? Have your say :-)

Luca.

[Edwin Kempin]

Sounds very cool :)

 

Luca.

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

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gustaf Lundh]

Cool stuff! Really looking forward to try it out!

> - Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

Please note: The Gerrit Trigger plugin does support consuming events from rabbit-mq and also from the Gerrit event-log plugin.

I think it is also worth nothing that Gerrit Trigger is push based and not pull based. Which makes quite a difference when you have a great amount of projects.

/Gustaf

[Luca Milanesio]

On 18 Aug 2017, at 12:19, Gustaf Lundh <gustaf...@axis.com> wrote:

Cool stuff! Really looking forward to try it out!

> - Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

Please note: The Gerrit Trigger plugin does support consuming events from rabbit-mq and also from the Gerrit event-log plugin.

Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a lot* of extra complexity and infrastructure :-(

Additionally, event-log plugin stores all the events on the Gerrit DB, which is *again* a lot of extra overhead :-((

I think it is also worth nothing that Gerrit Trigger is push based and not pull based. Which makes quite a difference when you have a great amount of projects.

My new plugin is push based as well, based on WebHooks.

But I agree with you, for a very large large scale setup, the Gerrit Trigger Plugin remains the 1st choice and the extra overhead of infrastructure is justified by the size of the installation.

For medium-small scale setups, it is way too complex for the people to setup and manage, based from the feedback I got from my clients :-(

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[Luca Milanesio]

On 18 Aug 2017, at 14:10, Robert Sandell <rsan...@cloudbees.com> wrote:

Cool,

So is this intended as a Branch API implementation? Something a la GitHub Branch Source Plugin?

Yes, exactly.

That would allow to have separate Jenkinsfile definitions even on different Changes and Patch-Sets.

Which is what my mind goes to when reading things like "Out-of-the-box integration with Gerrit validation workflow in the pipeline".

Yep.

From a quick reading I'm not sure that is what you are planning, it seems like something else?

Nope, that's exactly my goal.

The gerrit-branch-source-plugin is something that has been on my todo list for over two years and I haven't been able to free enough cycles to implement it yet. So getting that ghost off my chest would be nice ;)

Yes, I remember we talked about that during the last Jenkins World Summit in 2016, lots of people wanted that and came to our Booth asking if we did something in that direction.

This year, we'll have some answers for them :-)

Looking forward to get your reviews ;-)

Luca.

/B

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Luca Milanesio]

Hi Jesse,
thanks for the feedback, that's what I needed as guidance for finalising the plugin.

P.S. Would you have time at Jenkins World 2017 to pop up at the GerritForge booth and have a face-to-face chat on the plugins' evolutions?

> On 18 Aug 2017, at 16:39, Jesse Glick <jgl...@cloudbees.com> wrote:

>
> On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio
> <luca.mi...@gmail.com> wrote:
>> gerrit.withServer("http://gerrit:8080/", "gerrit") {
>

> I would strongly advise you *not* to use the “DSL style”
> (`workflow-cps` dependency). Define `Step`s and leave it at that.

The goal of this plugin is allow a Jenkinsfile developer *without any permissions* on the Jenkins configuration to integrate with a remote Gerrit server.
You can do it with the Declarative Pipeline as well in the scm section.

True that you *could* get that info from the SCM and not requiring any configuration at all: that could be a common sense default.
However, you could get the code via SSH and communicate with Gerrit REST API over HTTP using a different hostname.

>
>> gerrit.review("Verified", 1, "It works !")
>

> Why do you even need any special steps? IMO it should suffice to have
> a generic `Jenkinsfile`, and if the branch source is configured to
> post reviews, a successful build would be +1 and an unstable/failed
> build -1. This is what, say, `github-branch-source` does with the
> GitHub Status API.

In our Gerrit CI scenario we include as well the reason of the failure as "companion message".
Example: you failed the correct formatting check of three files => we include the name of the files in the review message.

Another example is the name of the review label: could be different than "Verified".
We have in Gerrit CI:
- Verified
- PolyGerrit Verified
- Library Compliance
- Codestyle

The logic of what to include in the message *stays* within the pipeline.
However, a common sense default could be the having a "Verified" label with +1 and -1 ... but it is not given for granted to be fully working in all projects.

Gerrit is a *fully featured* code-review system, whilst GitHub, GitLab and BitBucket are "lightweight" code reviews where possibly the defaults are good for everyone :-)

>
> (There could be steps added for advanced customization, like adding
> one vote per test stage or whatever, but you should be able to
> integrate with voting without making any mention of Gerrit in your
> `Jenkinsfile`.)

Yes, with some common-sense defaults.

>
> BTW did you implement `SCMNavigator`? I am not a Gerrit user but my
> understanding was that it should be possible to query the server for
> hosted repositories and set up jobs with `Jenkinsfile`s automatically,
> making it that much easier to get started in a big organization.

Not yet, but yes it is possible to list the projects using Gerrit REST API and auto-configure the jobs with a Jenkinsfile inside.
It would be actually really cool to show the "out-of-the-box" integration between Gerrit and Jenkins :-)

>
>> A second iteration of the plugin would have a Declarative pipeline
>> equivalent as well, which would require even less code required.
>

> See above—if there is nothing mandatory in the `Jenkinsfile`, there is
> no need to do anything special for Declarative.
>
> And note that DSL-style integrations will not work in Declarative.
> Only plain steps.

I know, I started with the DSL-style because is the most similar to what we have in gerrit-ci.gerritforge.com.
Next iteration will be towards a more Declarative-style pipeline as well.

>
>> A third iteration of the plugin would support BlueOcean as well, to have a
>> fully UX-integrated experience.
>

> I would hope that there is no special BlueOcean integration needed.
> You should only need to implement all applicable `scm-api` features,
> such as head categories.

At the moment already "shows-up" in BlueOcean, so we can "technically say" it is already integrated ... but it is not :-(
- You don't see the "Gerrit Changes tab"
- You have to visibility of the Changes / Patch-sets granularity
- You cannot navigate back and forth to Gerrit from BlueOcean

... that will come :-) thanks to suggestions and ideas like yours in this post :-)

>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0awVVQJn%2BPaJ%3DYV3g1%3DpU%2BgEwOq0kbBQp8x_xf771FfA%40mail.gmail.com.

[Luca Milanesio]

Hey Jesse,
that's absolutely fantastic feedback :-)

I believe we can close Phase #2 and #3 and have it finalised and announced officially at the Jenkins World Summit in SFO !!

> On 18 Aug 2017, at 17:04, Jesse Glick <jgl...@cloudbees.com> wrote:

>
> On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio
> <luca.mi...@gmail.com> wrote:
>> Would you have time at Jenkins World 2017 to pop up at the GerritForge booth and have a face-to-face chat on the plugins' evolutions?
>

> Absolutely! Grab me if I forget to come by.

Will do.

>
>> The goal of this plugin is allow a Jenkinsfile developer *without any permissions* on the Jenkins configuration to integrate with a remote Gerrit server.
>> You can do it with the Declarative Pipeline as well in the scm section.
>

> For a non-multibranch project, you mean—fine, that would be a good use
> for a custom `Step`.

I will be using in my workshop for multi-branch project as well, exactly because the *entire* configuration can stay inside the Jenkinsfile.
In large organisations there is a lot control and politics in the management of the global settings: having something that works nicely and is in control of the developer is *way better* than going through bureaucracy at times.

But the answer is: "it depends" :-)

>
>> In our Gerrit CI scenario we include as well the reason of the failure as "companion message".
>> Example: you failed the correct formatting check of three files => we include the name of the files in the review message.
>

> You could look for `ErrorAction` on the `FlowEndNode`, in case the
> build ended in an exception. That would handle many common cases.

BUT you may want to send feedback to Gerrit *during* the build flow as well.

Example of pipeline: steps => action on Gerrit
- scm checkout
- code style check => CodeStyle +1 / -1 to Gerrit
- build
- test (backend) => Backend Verified +1
- test (frontend) => Frontend Verified +1
- libraries compliance check => Library Compliance +1
- archive
- deploy
- integration test => Integration +1
- SUCCESS => Verified +1

As the entire pipeline could last even 20' or more ... it is *very valuable* to the developer to have feedback *as soon as possible* even if the build isn't complete.

>
> More broadly, perhaps the `build-failure-analyzer` plugin could offer
> an API for programmatically scraping the apparent problem from a
> build, for consumption by other plugins. Would need some design work.

Or just include the review() code inside a compensation try / catch of your steps.

>
>> Another example is the name of the review label: could be different than "Verified".
>> We have in Gerrit CI:
>> - Verified
>> - PolyGerrit Verified
>> - Library Compliance
>> - Codestyle
>

> Sure, this is what I meant by “advanced customization”.

Most of Gerrit users are sort of "advanced" :-)
The small teams are more likely to use GitHub or GitLab ... whilst Gerrit projects are typically composed by hundreds of people with complex requirements.

>
>> GitHub, GitLab and BitBucket are "lightweight" code reviews> where possibly the defaults are good for everyone
>

> Actually plenty of people request all sorts of customizations for
> GitHub behavior.

:-)

>
>> it is possible to list the projects using Gerrit REST API and auto-configure the jobs with a Jenkinsfile inside.
>> It would be actually really cool to show the "out-of-the-box" integration between Gerrit and Jenkins :-)
>

> Exactly.
>
> · Start Jenkins, finish setup wizard.
> · Click New Item, select “Gerrit Organization”.
> · Enter server URL where prompted, and admin credentials.
> · Start adding `Jenkinsfile`s in patches and relax.

That would be *super awesome*. Shall we put on-lien a demo-video once that scenario is finalised?

>
>> At the moment already "shows-up" in BlueOcean, so we can "technically say" it is already integrated ... but it is not :-(
>> - You don't see the "Gerrit Changes tab"
>> - You have to visibility of the Changes / Patch-sets granularity
>

> Not sure of details but it is possible `scm-api` already defines the
> SPIs you need here. Whether Blue Ocean calls them appropriately is
> another question.

Good to know, it should then be less complicated than I have originally envisaged.

>
>> - You cannot navigate back and forth to Gerrit from BlueOcean
>

> BO → Gerrit would probably be a “web URL” defined in `scm-api`. Gerrit
> → BO should be handled by `display-url-api`.

Cool :-)

>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3UYhhN9UUHx1B%3Dc%2B%2BZkh_fmc%3Dx4-DZzSh3iuiB8xPyNw%40mail.gmail.com.

[Alon Bar-Lev]

On 18 August 2017 at 12:04, Luca Milanesio <luca.mi...@gmail.com> wrote:
>
> Hi Gerrit and Jenkins Community,
> after over two years of iterations and improvements of the Gerrit CI workflow (https://gerrit-ci.gerritforge.com), I have decided that is about time to extract the logic of our workflow and make it available as a brand-new Jenkins plugin!
>

That's great!

Maybe you already thought of this... The only problem I have with the
current gerrit plugin is the visualization, maybe with deep knowledge
of jenkins it can be solved.

I have a single job that listens to gerrit events then executes the
pipeline, this works nice for all our projects and with low
maintenance, the problem is that jenkins visualization for all
projects go into this single project.
If it is possible to create a new "job" for every
project/branch/trigger so that stats like findbugs, errors, pipline
steps stats etc.. to be created dynamically it would be great.

I would like to have something like:

trigger = based on event (merge/review)
withJob("${server}/${branch}/${trigger}) {
//
}

A single listener job at jenkins side to visualized all gerrit
activity dynamically.

Regards,
Alon

[Vacelet, Manuel]

Hi Luca,

Jenkins World Conference is over, did you manage to showcase this new plugin ?

What's the status and what are the plans for the future ?

Manuel

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

---

You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.

[Luca Milanesio]

Hi Manuel,

I discussed the topic with Robert at the Jenkins World conference last week, and we agreed that:

1. More work is needed on the branch discovery side: I need to flag the ones coming from Gerrit Changes with a specific label

2. The plugin is going to be focused on the branch source API feature: Gerrit-branch-source similarly to GitHub-branch-source

3. Gerrit Trigger plugin will stay anyway for his specific use-case: triggering the build based on a Gerrit stream event

Does that answer your questions?

Luca.

[Vacelet, Manuel]

Hi Luca (congrats to the new gerrit maintainer BTW),

It does answer the question but raise a new one ;)

Have you an ETA in mind for all this ?

Manuel

[Luca Milanesio]

On 7 Sep 2017, at 14:48, Vacelet, Manuel <manuel....@enalean.com> wrote:

Hi Luca (congrats to the new gerrit maintainer BTW),

It does answer the question but raise a new one ;)

Have you an ETA in mind for all this ?

We are talking about weeks for sure, as I want to ship something fully documented and working.

I was planning to share it as "showcase" with a Docker compose containing:

- Gerrit 2.15 (or a pre-release)

- Jenkins 2.x with BlueOcean

I believe the coupling of BlueOcean + PolyGerrit will give the "business case" for many people to start adopting the two tools instead of heading to GitLab or similar.

Luca.

[Luca Milanesio]

Hi all,
the wait is finally over ... and the first Alpha release of the new Gerrit Code Review plugin for Jenkins is finally available!

I have submitted the request to get this hosted by the JenkinsCI organization and plugin central distribution ... however, in the meantime, you can download and install it from the GitHub repo at:
https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0

How to use it ... so, it is embarrassing simple!

1. Create a new multi-branch pipeline project
2. Select "Gerrit" as repository source
3. Add the Git/HTTP URL of your Gerrit repository (Git/SSH should work, but it won't allow submitting feedback to Gerrit yet)

... and there you go :-)

If you want to submit feedback to Gerrit in your pipeline, just add the following statement in your pipeline script:

gerrit.review("Verified", 1, "It works !")

(when it works)

OR

gerrit.review("Verified", -1, "Breaks the build ;-(")

(when it breaks)

*DISCLAIMER* this is an Alpha pre-release that is mainly focussed on getting early feedback on what are the most critical features to get implemented.

*Happy EARLY ADOPTION* to everyone, and thanks for your patience!

Luca.

> On 13 Dec 2017, at 07:03, Max Kovgan <m...@opsguru.io> wrote:
>
> hi, Luca!
> Add me to your 'early adopters'.
>
> M.
>
>
> On Tuesday, December 12, 2017 at 12:55:45 PM UTC+2, lucamilanesio wrote:
> Hi Sorin,
> I am aware that the new plugin is going to save a lot of time to a lot of people :-)
>
> Happy to see supporters and early adopters, and you'll definitely invited to be one of them.
>
> Luca.
>
>> On 12 Dec 2017, at 10:17, Sorin Ionuț Sbârnea <sorin....@gmail.com> wrote:
>>
>> Hi Luca,
>>
>> Your work on making Gerrit work with multibranch pipelines is of critical importance and I think it would be wise to share code even if you are going to rewrite it from scratch in the end. Sharing code is also a good risk mitigation as if something bad happens to you, at least someone else could continue the work instead of starting from scratch.
>>
>> I am more than willing to sacrifice most of my winter vacation time in order to make it work, just because this could be the kind of feature that would have a huge impact at my work. Imagine 1200 jobs defined on a single jenkins instance, their number could be cut by 85% if this would work (~7x duplication factor just because of maintenance branches).
>>
>> Or maybe some beer could help with motivation?
>>
>> On Monday, December 4, 2017 at 11:53:08 AM UTC, lucamilanesio wrote:
>> Apologies, as you may see by my delay in answering, I am very behind my scheduled backlog.
>> I have received useful feedback during the past Jenkins User Summit and I am working in fixing the code base in that direction.
>>
>> I wouldn't like to share it before the refactoring, otherwise I may break compatibility :-(
>>
>> Bear with me :-)
>>
>> Luca.
>>
>>> On 30 Nov 2017, at 16:17, Paolo Brocco <pa...@qontis.ch> wrote:
>>>
>>> Hi Luca,
>>>
>>> you announced this in September, I was wondering if in the meantime you could publish something? I'd be happy to test your plugin, since at work we actually need it...
>>>
>>> thanks for letting me know the status of your work, and if you have something to test,
>>>
>>> cheers, Paolo

>>>>> To unsubscribe, email repo-discuss...@googlegroups.com

>>>>> More info at http://groups.google.com/group/repo-discuss?hl=en
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>
>>>

>>> --

>>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

>>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a67552af-d495-4e3b-afb9-9742326c5f06%40googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>

>> --

>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d0a4c544-61dc-4757-b35c-7fc919b220ea%40googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

> --

> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a1da59ab-560b-41c3-a456-dc15a575e0d4%40googlegroups.com.

[Matthias Sohn]

On Wed, Jan 3, 2018 at 4:22 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:

Hi all,
the wait is finally over ... and the first Alpha release of the new Gerrit Code Review plugin for Jenkins is finally available!

I have submitted the request to get this hosted by the JenkinsCI organization and plugin central distribution ... however, in the meantime, you can download and install it from the GitHub repo at:
https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0

How to use it ... so, it is embarrassing simple!

1. Create a new multi-branch pipeline project
2. Select "Gerrit" as repository source
3. Add the Git/HTTP URL of your Gerrit repository (Git/SSH should work, but it won't allow submitting feedback to Gerrit yet)

... and there you go :-)

If you want to submit feedback to Gerrit in your pipeline, just add the following statement in your pipeline script:

gerrit.review("Verified", 1, "It works !")
(when it works)

OR

gerrit.review("Verified", -1, "Breaks the build ;-(")
(when it breaks)

*DISCLAIMER* this is an Alpha pre-release that is mainly focussed on getting early feedback on what are the most critical features to get implemented.

*Happy EARLY ADOPTION* to everyone, and thanks for your patience!

Luca.

nice, this looks great, will give it a try soon.

How are jobs triggered ? Are you using the gerrit webhooks plugin [1] for that ?

[1] https://gerrit.googlesource.com/plugins/webhooks/

-Matthias 

[lucamilanesio]

Yes, exactly.

The Jenkins URL to hook into is:

http://<jenkins host>:<jenkins port>/gerrit-hook/

Luca. 

-Matthias 

[David Pursehouse]

On Thursday, January 4, 2018 at 12:22:57 AM UTC+9, lucamilanesio wrote:

Hi all,
the wait is finally over ... and the first Alpha release of the new Gerrit Code Review plugin for Jenkins is finally available!

I have submitted the request to get this hosted by the JenkinsCI organization and plugin central distribution ... however, in the meantime, you can download and install it from the GitHub repo at:
https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0

Aside from binary distribution, how do you intend to manage code reviews?  Will you keep it on GitHub and use pull requests, or are you going to host it on gerrit-review.googlesource.com?

[luca.mi...@gmail.com]

Sent from my iPhone

This is actually a good idea, however we’ll have the problem of people expecting to raise PRs on the GitHub Jenkinsci organisation.

GerritHub would then be a better choice, because it allows to accept PRs as well, and review them through Gerrit.

Luca

[Sebastian Schuberth]

On Thursday, January 11, 2018 at 8:20:41 AM UTC+1, lucamilanesio wrote:

Aside from binary distribution, how do you intend to manage code reviews?  Will you keep it on GitHub and use pull requests, or are you going to host it on gerrit-review.googlesource.com?

This is actually a good idea, however we’ll have the problem of people expecting to raise PRs on the GitHub Jenkinsci organisation.

GerritHub would then be a better choice, because it allows to accept PRs as well, and review them through Gerrit.

Which reminds me again that I also wanted to ask for / work on a solution to allow Gerrit and GitHub to co-exist as review tools for a given project. GerritHub is a very nice idea, but it does not really work, e.g. in the sense that PR comments and Gerrit comments would be automatically and bidirectionally synced, which admittedly is hard. Maybe a better idea is to write a Gerrit plugin that supports PRs being reviewed solely in GitHub, and Gerrit reviews happening in Gerrit, but syncing up the repos once something gets merged on either side?

Regards,

Sebastian

[Matthew Webber]

On Wednesday, 3 January 2018 15:22:57 UTC, lucamilanesio wrote:

Hi all,
the wait is finally over ... and the first Alpha release of the new Gerrit Code Review plugin for Jenkins is finally available!

I have submitted the request to get this hosted by the JenkinsCI organization and plugin central distribution ... however, in the meantime, you can download and install it from the GitHub repo at:
https://github.com/GerritForge/gerrit-plugin/releases/tag/v0.1.0

<<snip>>

*DISCLAIMER* this is an Alpha pre-release that is mainly focussed on getting early feedback on what are the most critical features to get implemented.

That URL gives a 404. Is the alpha (or something later (<grin>) still available?

Thanks

[Luca Milanesio]

Hi Matthew, 

the project has now been moved to the JenkinsCI organisation.

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

As soon as CloudBees will approve my PR on their repository, it will be available through the Jenkins Plugin Manager as well :-)

Luca.

[Matthew Webber]

On Tuesday, 3 April 2018 17:30:54 UTC+1, lucamilanesio wrote:

Hi Matthew, 

the project has now been moved to the JenkinsCI organisation.

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

As soon as CloudBees will approve my PR on their repository, it will be available through the Jenkins Plugin Manager as well :-)

Luca.

Thanks Luca. We'll take a look, although I think it will come into its own when support for declarative pipeline is added.  

[Jonathan Nieder]

Hi,

This isn't exactly what you're asking for, but https://github.com/golang/go/wiki/GerritBot may be relevant to your interests.

Thanks,

Jonathan 

[lucamilanesio]

The final repository name is the following:

https://github.com/jenkinsci/gerrit-code-review-plugin

The Plugin has been renamed 'gerrit-code-review' because it seems that a few years ago a plugin was named 'gerrit' and thus the same name could not be reused.

I am planning to make the first release in the forthcoming days, so the Jenkins Users will have the first "Gerrit Code Review" plugin, which leverages (finally !) the Jenkins 2.0 features :-)

Luca.

[lucamilanesio]

The Gerrit Code Review plugin for Jenkins it is now officially available:

https://plugins.jenkins.io/gerrit-code-review

That means that people are able to discover it through the Jenkins plugin manager or through the jenkins.io search bar.

Luca.

[Mark Derricutt]

Giving this a shot but all I see in my jenkins build log is:

Gerrit Review Verified cannot be executed on branch null

I'm starting my pipeline with:

sh "git init"
sh "git fetch http://$GERRIT_HOST/$GERRIT_PROJECT $GERRIT_REFSPEC && git checkout FETCH_HEAD"

which lands me on a detached head. I'm calling it with:

gerrit.review("Verified", 1, "Project compilation successful ;-)")

I see https://wiki.jenkins.io/display/JENKINS/Gerrit+Code+Review+Plugin mentions checking out with:

checkout scm

so maybe that's where I'm going wrong.

Any suggestions?

Mark

On 4 Apr 2018, at 10:33, lucamilanesio wrote:

The final repository name is the following:

https://github.com/jenkinsci/gerrit-code-review-plugin

The Plugin has been renamed 'gerrit-code-review' because it seems that a few years ago a plugin was named 'gerrit' and thus the same name could not be reused.

I am planning to make the first release in the forthcoming days, so the Jenkins Users will have the first "Gerrit Code Review" plugin, which leverages (finally !) the Jenkins 2.0 features :-)

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

[Luca Milanesio]

On 13 Apr 2018, at 00:20, Mark Derricutt <ma...@talios.com> wrote:

Giving this a shot but all I see in my jenkins build log is:

Gerrit Review Verified cannot be executed on branch null

I'm starting my pipeline with:

sh "git init"
sh "git fetch http://$GERRIT_HOST/$GERRIT_PROJECT $GERRIT_REFSPEC && git checkout FETCH_HEAD"

No need to do this: just to a simple 'checkout scm'.

The plugin gets automatically the gerrit host, project and ref for you :-)

which lands me on a detached head. I'm calling it with:

gerrit.review("Verified", 1, "Project compilation successful ;-)")

I see https://wiki.jenkins.io/display/JENKINS/Gerrit+Code+Review+Plugin mentions checking out with:

checkout scm

so maybe that's where I'm going wrong.

The plugin uses the Gerrit API to understand the exact ref to use.

Doesn't use anymore the old-style Gerrit Trigger Plugin envs.

Trust me ... it is all "working by magic" ... as it should be :-)

[David Pursehouse]

On Fri, Apr 13, 2018 at 8:23 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

On 13 Apr 2018, at 00:20, Mark Derricutt <ma...@talios.com> wrote:

Giving this a shot but all I see in my jenkins build log is:

Gerrit Review Verified cannot be executed on branch null

I'm starting my pipeline with:

sh "git init"
sh "git fetch http://$GERRIT_HOST/$GERRIT_PROJECT $GERRIT_REFSPEC && git checkout FETCH_HEAD"

No need to do this: just to a simple 'checkout scm'.

The plugin gets automatically the gerrit host, project and ref for you :-)

which lands me on a detached head. I'm calling it with:

gerrit.review("Verified", 1, "Project compilation successful ;-)")

I see https://wiki.jenkins.io/display/JENKINS/Gerrit+Code+Review+Plugin mentions checking out with:

checkout scm

so maybe that's where I'm going wrong.

The plugin uses the Gerrit API to understand the exact ref to use.

Doesn't use anymore the old-style Gerrit Trigger Plugin envs.

Trust me ... it is all "working by magic" ... as it should be :-)

Are you planning to update the README of the project with a bit more detail on how it's supposed to be set up?

I know the setup is intended to be as simple and "working by magic" as much as possible, but I think it would help to have a bit more guidance in the documentation.

 

Any suggestions?

Mark

On 4 Apr 2018, at 10:33, lucamilanesio wrote:

The final repository name is the following:

https://github.com/jenkinsci/gerrit-code-review-plugin

The Plugin has been renamed 'gerrit-code-review' because it seems that a few years ago a plugin was named 'gerrit' and thus the same name could not be reused.

I am planning to make the first release in the forthcoming days, so the Jenkins Users will have the first "Gerrit Code Review" plugin, which leverages (finally !) the Jenkins 2.0 features :-)

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

--

[Luca Milanesio]

On 13 Apr 2018, at 00:45, David Pursehouse <david.pu...@gmail.com> wrote:

On Fri, Apr 13, 2018 at 8:23 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

On 13 Apr 2018, at 00:20, Mark Derricutt <ma...@talios.com> wrote:

Giving this a shot but all I see in my jenkins build log is:

Gerrit Review Verified cannot be executed on branch null

I'm starting my pipeline with:

sh "git init"
sh "git fetch http://$GERRIT_HOST/$GERRIT_PROJECT $GERRIT_REFSPEC && git checkout FETCH_HEAD"

No need to do this: just to a simple 'checkout scm'.

The plugin gets automatically the gerrit host, project and ref for you :-)

which lands me on a detached head. I'm calling it with:

gerrit.review("Verified", 1, "Project compilation successful ;-)")

I see https://wiki.jenkins.io/display/JENKINS/Gerrit+Code+Review+Plugin mentions checking out with:

checkout scm

so maybe that's where I'm going wrong.

The plugin uses the Gerrit API to understand the exact ref to use.

Doesn't use anymore the old-style Gerrit Trigger Plugin envs.

Trust me ... it is all "working by magic" ... as it should be :-)

Are you planning to update the README of the project with a bit more detail on how it's supposed to be set up?

I know the setup is intended to be as simple and "working by magic" as much as possible, but I think it would help to have a bit more guidance in the documentation.

Yes, that's in the plan :-)

My intention is to conform as much as possible to the standard way that other plugins are behaving with Gerrit.

I would like to display as well the changes under review under its appropriate "Pull Request" tab instead of displaying the Gerrit ref-spec in the branch name.

[Alon Bar-Lev]

Hi,
Just an idea...
In addition to a message and vote text, allow also to add a file
comment based on file name and line number.
This will enable a plugin similar to sonar-gerrit[1] to be ported out
of the gerrit trigger or will be possible even perform the logic of it
purely in groovy by reading the sonar or any static analysis report.
Regards,
Alon

[1] https://wiki.jenkins.io/display/JENKINS/Sonar+Gerrit

[Mark Derricutt]

On 13 Apr 2018, at 11:23, Luca Milanesio wrote:

No need to do this: just to a simple 'checkout scm'.

You say that... but that just failed to checkout any code and just broke 50 jobs :)

I'm using a generic GerritJenkinsJobFile was a separate git repo. checkout scp checked out the job file repo, not the project repo.

[luca.mi...@gmail.com]

Sent from my iPhone

On 13 Apr 2018, at 04:09, Mark Derricutt <ma...@talios.com> wrote:

On 13 Apr 2018, at 11:23, Luca Milanesio wrote:

No need to do this: just to a simple 'checkout scm'.

You say that... but that just failed to checkout any code and just broke 50 jobs :)

I'm using a generic GerritJenkinsJobFile was a separate git repo. checkout scp checked out the job file repo, not the project repo.

So, your project is not a multi-branch Pipeline, isn’t it?

Luca

[luca.mi...@gmail.com]

That would be really cool indeed :-)

Have you submitted the proposal to the Jenkins CI issue tracker?

Luca

Sent from my iPhone

[Alon Bar-Lev]

On Fri, Apr 13, 2018 at 9:29 AM, <luca.mi...@gmail.com> wrote:
>
> That would be really cool indeed :-)
>
> Have you submitted the proposal to the Jenkins CI issue tracker?

Now I have :)

Support file based comments
https://issues.jenkins-ci.org/browse/JENKINS-50783

[Mark Derricutt]

On 13 Apr 2018, at 18:29, luca.mi...@gmail.com wrote:

So, your project is not a multi-branch Pipeline, isn’t it?

We have about 50 projects all reusing the same JenkinsFile, from a separate git repo.

99% of the projects only have one 'develop' branch for reviews, some have shortlived/rarely used support branches tho.

[Mark Derricutt]

I guess I should read that first line about starting with a multi-branch Pipeline job - I'll have to go create a new job like that and see what the XML job looks like, and craft a script to remake all our jobs.  I'm not actually sure what kind of pipeline job I created initially, I've usually just been creating new jobs based off the a previous one and changing the gerrit project/ref in the scm section.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

[lucamilanesio]

The v0.3.1 of the Gerrit Code Review plugin has been released today, see my feedback below on your use-case.

On Thursday, April 19, 2018 at 12:56:59 PM UTC+1, Mark Derricutt wrote:

I guess I should read that first line about starting with a multi-branch Pipeline job

Not anymore:  the plugin supports (as well) the simple Pipeline Job with invocation triggered by Stream Events using the Gerrit Trigger Plugin.

 

- I'll have to go create a new job like that and see what the XML job looks like, and craft a script to remake all our jobs.  I'm not actually sure what kind of pipeline job I created initially, I've usually just been creating new jobs based off the a previous one and changing the gerrit project/ref in the scm section.

It would be up to you: if you use the multi-branch Jenkinsfile pipeline project, everything is automatic.

Otherwise, the Gerrit plugin will support as well the existing variables created by the Gerrit Trigger Plugin.

Kudos to Alon Bar-Lev for implementing the support and starting contributing to this plugin.

Luca.