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 <luca.milane...@gmail.com>: > > On 18 Aug 2017, at 12:19, Gustaf Lundh <gustaf.lu...@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 > > > 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 repo-discuss+unsubscr...@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+unsubscr...@googlegroups.com. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.
