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
>>> 
>>> On Friday, September 8, 2017 at 12:00:50 AM UTC+2, lucamilanesio wrote:
>>> 
>>>> 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
>>>>  
>>>> 
>>>> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio <luca.mi...@gmail.com> 
>>>> wrote:
>>>> 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
>>>>> 
>>>>> On Fri, Aug 18, 2017 at 11:04 AM, 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!
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> -- 
>>>>> 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-dev+unsubscr...@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.
> 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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/56B9EF04-9591-4DFA-BBF9-D2E5B6C0204C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to