> 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] > <mailto:[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] >> <mailto:[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/67524463-9EDF-490D-A92C-D9DA03B2B3A3%40gmail.com. For more options, visit https://groups.google.com/d/optout.
