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 <jgl...@cloudbees.com> wrote:
> 
> On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio
> <luca.milane...@gmail.com> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
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.

Reply via email to