Hi Luca,

Have you had a chance to publish this to github?

On Friday, August 18, 2017 at 2:17:00 AM UTC-7, Luca Milanesio wrote:
>
> Posting to the jenkinsci-users mailing list as well: even if I mainly 
> needed feedback from the plugins developers, feedback from a 
> user-perspective of the new plugin would be *really appreciated* as well :-)
>
> -- See below the original post --
>
> 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.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/2c459ab4-cc59-42b4-a02d-92a1069a56fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to