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 <
jgl...@cloudbees.com> wrote:
>
> On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio
> <
luca.mi...@gmail.com> 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
jenkinsci-de...@googlegroups.com.
> 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.