Hey Jesse, that's absolutely fantastic feedback :-) I believe we can close Phase #2 and #3 and have it finalised and announced officially at the Jenkins World Summit in SFO !!
> On 18 Aug 2017, at 17:04, Jesse Glick <[email protected]> wrote: > > On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio > <[email protected]> wrote: >> 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? > > Absolutely! Grab me if I forget to come by. Will do. > >> 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. > > For a non-multibranch project, you mean—fine, that would be a good use > for a custom `Step`. I will be using in my workshop for multi-branch project as well, exactly because the *entire* configuration can stay inside the Jenkinsfile. In large organisations there is a lot control and politics in the management of the global settings: having something that works nicely and is in control of the developer is *way better* than going through bureaucracy at times. But the answer is: "it depends" :-) > >> 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. > > You could look for `ErrorAction` on the `FlowEndNode`, in case the > build ended in an exception. That would handle many common cases. BUT you may want to send feedback to Gerrit *during* the build flow as well. Example of pipeline: steps => action on Gerrit - scm checkout - code style check => CodeStyle +1 / -1 to Gerrit - build - test (backend) => Backend Verified +1 - test (frontend) => Frontend Verified +1 - libraries compliance check => Library Compliance +1 - archive - deploy - integration test => Integration +1 - SUCCESS => Verified +1 As the entire pipeline could last even 20' or more ... it is *very valuable* to the developer to have feedback *as soon as possible* even if the build isn't complete. > > More broadly, perhaps the `build-failure-analyzer` plugin could offer > an API for programmatically scraping the apparent problem from a > build, for consumption by other plugins. Would need some design work. Or just include the review() code inside a compensation try / catch of your steps. > >> 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 > > Sure, this is what I meant by “advanced customization”. Most of Gerrit users are sort of "advanced" :-) The small teams are more likely to use GitHub or GitLab ... whilst Gerrit projects are typically composed by hundreds of people with complex requirements. > >> GitHub, GitLab and BitBucket are "lightweight" code reviews> where possibly >> the defaults are good for everyone > > Actually plenty of people request all sorts of customizations for > GitHub behavior. :-) > >> 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 :-) > > Exactly. > > · Start Jenkins, finish setup wizard. > · Click New Item, select “Gerrit Organization”. > · Enter server URL where prompted, and admin credentials. > · Start adding `Jenkinsfile`s in patches and relax. That would be *super awesome*. Shall we put on-lien a demo-video once that scenario is finalised? > >> 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 > > Not sure of details but it is possible `scm-api` already defines the > SPIs you need here. Whether Blue Ocean calls them appropriately is > another question. Good to know, it should then be less complicated than I have originally envisaged. > >> - You cannot navigate back and forth to Gerrit from BlueOcean > > BO → Gerrit would probably be a “web URL” defined in `scm-api`. Gerrit > → BO should be handled by `display-url-api`. Cool :-) > > -- > 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/CANfRfr3UYhhN9UUHx1B%3Dc%2B%2BZkh_fmc%3Dx4-DZzSh3iuiB8xPyNw%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/4A33954B-517B-42AA-9345-5FE387E42BCC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
