Cool, So is this intended as a Branch API <https://github.com/jenkinsci/branch-api-plugin/blob/master/docs/user.adoc> implementation? Something a la GitHub Branch Source Plugin <https://wiki.jenkins.io/display/JENKINS/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 2017-08-18 13:44 GMT+02:00 Luca Milanesio <[email protected]>: > > On 18 Aug 2017, at 12:19, Gustaf Lundh <[email protected]> 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 > > > On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio 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-driv >> en-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. > > > -- Robert Sandell *Software Engineer* *CloudBees Inc.* -- 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/CALzHZS3gX-4cxFF%3DGonZ7sTWFgWqvkmzisC%2BMVuwLoaR1JcAdA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
