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 <[email protected] <javascript:>> > 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> 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 [email protected] >>>> 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 [email protected]. >>>> 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 [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/a67552af-d495-4e3b-afb9-9742326c5f06%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/a67552af-d495-4e3b-afb9-9742326c5f06%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. 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.
