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

[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 :-(

/Gustaf

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

[Robert Sandell]

Cool,

So is this intended as a Branch API implementation? Something a la GitHub Branch Source Plugin? Which is what my mind goes to when reading things like "Out-of-the-box integration with Gerrit validation workflow in the pipeline".

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

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

/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]

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.

[Jesse Glick]

Please comment on https://issues.jenkins-ci.org/browse/JENKINS-38046
letting watchers know that this is finally available.

[lucamilanesio]

Sure, will do it now.

Luca.

[Jesse Glick]

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.

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

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

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.

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

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

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

[Jesse Glick]

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.

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

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

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.

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

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

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

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

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

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

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

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]

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.

Manuel

[Stephen Connolly]

I recommend using the gitea plugin as a "clean" example of a branch source, as it is relatively feature complete (gaps are api gaps in gitea itself) and free of the rate limit and class migration noise in github and Bitbucket branch source plugins 

--
--
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/67524463-9EDF-490D-A92C-D9DA03B2B3A3%40gmail.com.

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

--

Sent from my phone

[Paolo Brocco]

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

Manuel

 

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

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.

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.

[Sorin Ionuț Sbârnea]

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?

[Luca Milanesio]

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.

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

[Max Kovgan]

hi, Luca!

Add me to your 'early adopters'.

M.

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

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

[Jesse Glick]

On Wed, Jan 3, 2018 at 10:22 AM, Luca Milanesio
<luca.mi...@gmail.com> wrote:
> 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 !")

I would urge you to use a plain old `Step` (no `workflow-cps`
dependency except in `test` scope, no `GerritDSL` + `Gerrit.groovy`),
e.g.:

gerritReview status: 'Verified', vote: 1, message: 'It works!'

You get a simpler implementation, *Pipeline Syntax* support,
compatibility with Declarative Pipeline, and the chance to work
unmodified with possible future execution engines.

[Luca Milanesio]

Good point: let me try to see what's the effort for the declarative pipeline compatibility :-)

Luca.

> --
> 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/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%40mail.gmail.com.

[lucamilanesio]

I've taken now https://github.com/jenkinsci/pipeline-utility-steps-plugin as an example of simple utility steps and will add a brand-new implementation in Java.

On Thursday, January 4, 2018 at 7:57:15 AM UTC, lucamilanesio wrote:

Good point: let me try to see what's the effort for the declarative pipeline compatibility :-)

Luca.

> On 3 Jan 2018, at 18:16, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> On Wed, Jan 3, 2018 at 10:22 AM, Luca Milanesio
> <luca.mi...@gmail.com> wrote:
>> 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 !")
>
> I would urge you to use a plain old `Step` (no `workflow-cps`
> dependency except in `test` scope, no `GerritDSL` + `Gerrit.groovy`),
> e.g.:
>
> gerritReview status: 'Verified', vote: 1, message: 'It works!'
>
> You get a simpler implementation, *Pipeline Syntax* support,
> compatibility with Declarative Pipeline, and the chance to work
> unmodified with possible future execution engines.
>
> --
> 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-dev+unsubscribe@googlegroups.com.

[Jesse Glick]

On Thu, Jan 4, 2018 at 4:53 AM, lucamilanesio <luca.mi...@gmail.com> wrote:
> I've taken now https://github.com/jenkinsci/pipeline-utility-steps-plugin as
> an example of simple utility steps

Best to start with the official documentation:

https://github.com/jenkinsci/workflow-step-api-plugin/blob/master/README.md

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

Sent from my iPhone

On 11 Jan 2018, at 02:18, David Pursehouse <david.pu...@gmail.com> wrote:

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?

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

[Sorin Sbarnea]

First let me thank Luca for his work on this plugin. I started to test it, raised few bugs and also working on implementing full JJB support for it.

Regarding contributions, I think that it would be the best to follow Jenkins CI workflow (github with PR) here and avoid gerrit one.

I see two important reasons: all jenkins plugins use the same process, diverging from standard is not good. Second, the plugin is too new to be considered stable, better to use a common/tested/stable process and focus on improving the plugin.

Moving the repo under jenkinsci and enabling Jenkins ci testing would be the next natural step but there is no pressure.

Now I only hope that I will see more activity on the issue tracker and as PRs being raised. I am eager to see it as reaching a stable release and I am sure that there are lots of people that could help with that.

-- sorin

> On 3 Jan 2018, at 18:16, Jesse Glick <jgl...@cloudbees.com> wrote:
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/E3pvb0WH4Ls/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%40mail.gmail.com.

[Luca Milanesio]

On 19 Jan 2018, at 10:29, Sorin Sbarnea <sorin....@gmail.com> wrote:

First let me thank Luca for his work on this plugin. I started to test it, raised few bugs and also working on implementing full JJB support for it.

Thanks for trying it out :-) I always appreciated early feedback.

It is still a pre-alpha, so it is not suitable yet for production ... I am using it anyway on a daily basis and it works for me. However, still needs a lot of improvements.

Regarding contributions, I think that it would be the best to follow Jenkins CI workflow (github with PR) here and avoid gerrit one.

I believe in dogfooding and innovation, rather than "standards". However, I see your point.

It will stay on GitHub and reviews will be welcome from both GerritHub and GitHub sides :-)

I see two important reasons: all jenkins plugins use the same process, diverging from standard is not good.

Why? The audience is "people that work with Jenkins and Gerrit" and I'd leave it to them to decide the best tool to do reviews.

Second, the plugin is too new to be considered stable,

It isn't a stable release but rather a pre-alpha.

better to use a common/tested/stable process and focus on improving the plugin. 

Gerrit Code Review and GitHub are both common, tested and stable processed IMHO. They have been around for ~ 10 years now.

GerritHub.io was launched in 2013, 5 years ago, has 99.99% uptime and over 25k active users.

Moving the repo under jenkinsci and enabling Jenkins ci testing would be the next natural step but there is no pressure.

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

Now I only hope that I will see more activity on the issue tracker and as PRs being raised. I am eager to see it as reaching a stable release and I am sure that there are lots of people that could help with that.

I would have to close them and re-open them on the JenkinsCI project: the GerritForge one was just the pre-alpha inception.

-- sorin

On 3 Jan 2018, at 18:16, Jesse Glick <jgl...@cloudbees.com> wrote:

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

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 !")

I would urge you to use a plain old `Step` (no `workflow-cps`
dependency except in `test` scope, no `GerritDSL` + `Gerrit.groovy`),
e.g.:

gerritReview status: 'Verified', vote: 1, message: 'It works!'

You get a simpler implementation, *Pipeline Syntax* support,
compatibility with Declarative Pipeline, and the chance to work
unmodified with possible future execution engines.

-- 
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/E3pvb0WH4Ls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3DWgR4sZktwYLB_wuynLL8TURTMF-6F_f2wkUhTBoXBA%40mail.gmail.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/E4C7F294-9200-4C1A-95BF-906A99154640%40gmail.com.

[Sorin Ionuț Sbârnea]

I hope you can enable the issue tracker on the new location.

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

I hope CloudBees would not force use of JIRA. Using GitHub issue tracker seems much easier, especially for a new project.

As soon as I will spot a .gitreview file in the root folder, I will now which is the preferred way to contribute.

Thanks

Sorin

[Jesse Glick]

On Fri, Jan 19, 2018 at 2:48 PM, Sorin Ionuț Sbârnea
<sorin....@gmail.com> wrote:
> I hope CloudBees would not force use of JIRA. Using GitHub issue tracker
> seems much easier, especially for a new project.

This is not a CloudBees issue. The Jenkins project recommends use of
JIRA for all components, and disabling GitHub issues, but that is for
each repository’s maintainer to decide.