Hi Jesse, thanks for the feedback, that's what I needed as guidance for finalising the plugin.
P.S. Would you have time at Jenkins World 2017 to pop up at the GerritForge booth and have a face-to-face chat on the plugins' evolutions? > On 18 Aug 2017, at 16:39, Jesse Glick <[email protected]> wrote: > > On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio > <[email protected]> wrote: >> gerrit.withServer("http://gerrit:8080/";, "gerrit") { > > I would strongly advise you *not* to use the “DSL style” > (`workflow-cps` dependency). Define `Step`s and leave it at that. The goal of this plugin is allow a Jenkinsfile developer *without any permissions* on the Jenkins configuration to integrate with a remote Gerrit server. You can do it with the Declarative Pipeline as well in the scm section. True that you *could* get that info from the SCM and not requiring any configuration at all: that could be a common sense default. However, you could get the code via SSH and communicate with Gerrit REST API over HTTP using a different hostname. > >> gerrit.review("Verified", 1, "It works !") > > Why do you even need any special steps? IMO it should suffice to have > a generic `Jenkinsfile`, and if the branch source is configured to > post reviews, a successful build would be +1 and an unstable/failed > build -1. This is what, say, `github-branch-source` does with the > GitHub Status API. In our Gerrit CI scenario we include as well the reason of the failure as "companion message". Example: you failed the correct formatting check of three files => we include the name of the files in the review message. Another example is the name of the review label: could be different than "Verified". We have in Gerrit CI: - Verified - PolyGerrit Verified - Library Compliance - Codestyle The logic of what to include in the message *stays* within the pipeline. However, a common sense default could be the having a "Verified" label with +1 and -1 ... but it is not given for granted to be fully working in all projects. Gerrit is a *fully featured* code-review system, whilst GitHub, GitLab and BitBucket are "lightweight" code reviews where possibly the defaults are good for everyone :-) > > (There could be steps added for advanced customization, like adding > one vote per test stage or whatever, but you should be able to > integrate with voting without making any mention of Gerrit in your > `Jenkinsfile`.) Yes, with some common-sense defaults. > > BTW did you implement `SCMNavigator`? I am not a Gerrit user but my > understanding was that it should be possible to query the server for > hosted repositories and set up jobs with `Jenkinsfile`s automatically, > making it that much easier to get started in a big organization. Not yet, but yes it is possible to list the projects using Gerrit REST API and auto-configure the jobs with a Jenkinsfile inside. It would be actually really cool to show the "out-of-the-box" integration between Gerrit and Jenkins :-) > >> A second iteration of the plugin would have a Declarative pipeline >> equivalent as well, which would require even less code required. > > See above—if there is nothing mandatory in the `Jenkinsfile`, there is > no need to do anything special for Declarative. > > And note that DSL-style integrations will not work in Declarative. > Only plain steps. I know, I started with the DSL-style because is the most similar to what we have in gerrit-ci.gerritforge.com. Next iteration will be towards a more Declarative-style pipeline as well. > >> A third iteration of the plugin would support BlueOcean as well, to have a >> fully UX-integrated experience. > > I would hope that there is no special BlueOcean integration needed. > You should only need to implement all applicable `scm-api` features, > such as head categories. At the moment already "shows-up" in BlueOcean, so we can "technically say" it is already integrated ... but it is not :-( - You don't see the "Gerrit Changes tab" - You have to visibility of the Changes / Patch-sets granularity - You cannot navigate back and forth to Gerrit from BlueOcean ... that will come :-) thanks to suggestions and ideas like yours in this post :-) > > -- > 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/CANfRfr0awVVQJn%2BPaJ%3DYV3g1%3DpU%2BgEwOq0kbBQp8x_xf771FfA%40mail.gmail.com. > For more options, visit 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/04DB6A47-4FD2-4017-AACD-3D5BF20F7737%40gmail.com. For more options, visit https://groups.google.com/d/optout.
