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] > <mailto:[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 <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 > <https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger>) enough? > We couldn't use it against gerrit-review.googlesource.com > <http://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/ <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 <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 > > <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] > <mailto:repo-discuss%[email protected]> > More info at http://groups.google.com/group/repo-discuss?hl=en > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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/1F0734FE-41C5-4CE1-B88C-E630986C13A6%40gmail.com. For more options, visit https://groups.google.com/d/optout.
