[Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio
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."
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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D9530F31-F753-4339-AAF5-62449FFCC607%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio

On 18 Aug 2017, at 12:19, Gustaf Lundh <[hidden email]> wrote:

Cool stuff! Really looking forward to try it out!

> - Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

Please note: The Gerrit Trigger plugin does support consuming events from rabbit-mq and also from the Gerrit event-log plugin.

Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a lot* of extra complexity and infrastructure :-(
Additionally, event-log plugin stores all the events on the Gerrit DB, which is *again* a lot of extra overhead :-((


I think it is also worth nothing that Gerrit Trigger is push based and not pull based. Which makes quite a difference when you have a great amount of projects.

My new plugin is push based as well, based on WebHooks.
But I agree with you, for a very large large scale setup, the Gerrit Trigger Plugin remains the 1st choice and the extra overhead of infrastructure is justified by the size of the installation.
For medium-small scale setups, it is way too complex for the people to setup and manage, based from the feedback I got from my clients :-(


/Gustaf


On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio wrote:
Hi Gerrit and Jenkins Community,
after over two years of iterations and improvements of the Gerrit CI workflow (<a href="https://gerrit-ci.gerritforge.com/" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgerrit-ci.gerritforge.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFOtIPc-3lXIvX_Y0uGa1SvNWGQ6g';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgerrit-ci.gerritforge.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFOtIPc-3lXIvX_Y0uGa1SvNWGQ6g';return true;" class="">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 (<a href="https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FGerrit%2BTrigger\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNElNo-NJGQwO4Wvsg5rIirtRGYkUw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FGerrit%2BTrigger\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNElNo-NJGQwO4Wvsg5rIirtRGYkUw';return true;" class="">https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger) enough?
We couldn't use it against <a href="http://gerrit-review.googlesource.com/" target="_blank" rel="nofollow" onmousedown="this.href='http://gerrit-review.googlesource.com';return true;" onclick="this.href='http://gerrit-review.googlesource.com';return true;" class="">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("<a href="http://gerrit:8080/" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fgerrit%3A8080%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8QILAfpfqbQUFKgDx8v5DKCqtlQ';return true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fgerrit%3A8080%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG8QILAfpfqbQUFKgDx8v5DKCqtlQ';return true;" class="">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:
- <a href="https://gerrit-review.example.com/" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgerrit-review.example.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH1ApKS45xOgHzCJb4mFlVnBFwgyA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fgerrit-review.example.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH1ApKS45xOgHzCJb4mFlVnBFwgyA';return true;" class="">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."
(<a href="https://jenkinsworld20162017.sched.com/event/APTd/data-driven-pipeline-workshop-free" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkinsworld20162017.sched.com%2Fevent%2FAPTd%2Fdata-driven-pipeline-workshop-free\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGE5ATDvr7Lzts0qyGJQf_wOiwdbg';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkinsworld20162017.sched.com%2Fevent%2FAPTd%2Fdata-driven-pipeline-workshop-free\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGE5ATDvr7Lzts0qyGJQf_wOiwdbg';return true;" class="">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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/59103491-CB6E-4F16-953F-43FBE625EDC9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Robert Sandell-2
Cool,
So is this intended as a Branch API implementation? Something a la GitHub Branch Source Plugin? Which is what my mind goes to when reading things like "Out-of-the-box integration with Gerrit validation workflow in the pipeline".
From a quick reading I'm not sure that is what you are planning, it seems like something else?

The gerrit-branch-source-plugin is something that has been on my todo list for over two years and I haven't been able to free enough cycles to implement it yet. So getting that ghost off my chest would be nice ;)

/B

2017-08-18 13:44 GMT+02:00 Luca Milanesio <[hidden email]>:

On 18 Aug 2017, at 12:19, Gustaf Lundh <[hidden email]> wrote:

Cool stuff! Really looking forward to try it out!

> - Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

Please note: The Gerrit Trigger plugin does support consuming events from rabbit-mq and also from the Gerrit event-log plugin.

Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a lot* of extra complexity and infrastructure :-(
Additionally, event-log plugin stores all the events on the Gerrit DB, which is *again* a lot of extra overhead :-((


I think it is also worth nothing that Gerrit Trigger is push based and not pull based. Which makes quite a difference when you have a great amount of projects.

My new plugin is push based as well, based on WebHooks.
But I agree with you, for a very large large scale setup, the Gerrit Trigger Plugin remains the 1st choice and the extra overhead of infrastructure is justified by the size of the installation.
For medium-small scale setups, it is way too complex for the people to setup and manage, based from the feedback I got from my clients :-(


/Gustaf


On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio wrote:
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."
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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.




--
Robert Sandell
Software Engineer
CloudBees Inc.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3gX-4cxFF%3DGonZ7sTWFgWqvkmzisC%2BMVuwLoaR1JcAdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio

On 18 Aug 2017, at 14:10, Robert Sandell <[hidden email]> wrote:

Cool,
So is this intended as a Branch API implementation? Something a la GitHub Branch Source Plugin?

Yes, exactly.
That would allow to have separate Jenkinsfile definitions even on different Changes and Patch-Sets.

Which is what my mind goes to when reading things like "Out-of-the-box integration with Gerrit validation workflow in the pipeline".

Yep.

From a quick reading I'm not sure that is what you are planning, it seems like something else?

Nope, that's exactly my goal.


The gerrit-branch-source-plugin is something that has been on my todo list for over two years and I haven't been able to free enough cycles to implement it yet. So getting that ghost off my chest would be nice ;)

Yes, I remember we talked about that during the last Jenkins World Summit in 2016, lots of people wanted that and came to our Booth asking if we did something in that direction.
This year, we'll have some answers for them :-)

Looking forward to get your reviews ;-)

Luca.


/B

2017-08-18 13:44 GMT+02:00 Luca Milanesio <[hidden email]>:

On 18 Aug 2017, at 12:19, Gustaf Lundh <[hidden email]> wrote:

Cool stuff! Really looking forward to try it out!

> - Stability: stream-events are based on SSH, which isn't scalable, reliable against downtime, etc.

Please note: The Gerrit Trigger plugin does support consuming events from rabbit-mq and also from the Gerrit event-log plugin.

Yes, with RabbitMQ becomes much more reliable and scalable ... but it is *a lot* of extra complexity and infrastructure :-(
Additionally, event-log plugin stores all the events on the Gerrit DB, which is *again* a lot of extra overhead :-((


I think it is also worth nothing that Gerrit Trigger is push based and not pull based. Which makes quite a difference when you have a great amount of projects.

My new plugin is push based as well, based on WebHooks.
But I agree with you, for a very large large scale setup, the Gerrit Trigger Plugin remains the 1st choice and the extra overhead of infrastructure is justified by the size of the installation.
For medium-small scale setups, it is way too complex for the people to setup and manage, based from the feedback I got from my clients :-(


/Gustaf


On Friday, August 18, 2017 at 11:04:41 AM UTC+2, lucamilanesio wrote:
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."
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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.




--
Robert Sandell
Software Engineer
CloudBees Inc.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CF1E920B-B258-4D9C-BF57-D21E7118DFEC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Jesse Glick-4
Please comment on https://issues.jenkins-ci.org/browse/JENKINS-38046
letting watchers know that this is finally available.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0Nimb%3DxE7ieHDhVXzJ0Z7pkGi8e%3DoX_v8LmyDadTGbNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio
Sure, will do it now.

Luca.

On Friday, August 18, 2017 at 4:29:59 PM UTC+1, Jesse Glick wrote:
Please comment on <a href="https://issues.jenkins-ci.org/browse/JENKINS-38046" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-38046\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHgVxqDvdPzZ_hq7n9kXMwXQnto_g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-38046\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHgVxqDvdPzZ_hq7n9kXMwXQnto_g&#39;;return true;">https://issues.jenkins-ci.org/browse/JENKINS-38046
letting watchers know that this is finally available.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/28a29547-d830-413e-87fb-f0528a9a2c77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Jesse Glick-4
In reply to this post by Luca Milanesio
On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio
<[hidden email]> 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.

>             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.

(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`.)

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.

> 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.

> 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.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio
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 <[hidden email]> wrote:
>
> On Fri, Aug 18, 2017 at 5:04 AM, Luca Milanesio
> <[hidden email]> 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 [hidden email].
> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Jesse Glick-4
On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio
<[hidden email]> 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.

> 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`.

> 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.

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.

> 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”.

> 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.

> 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.

> - 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`.

--
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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio
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 <[hidden email]> wrote:
>
> On Fri, Aug 18, 2017 at 11:52 AM, Luca Milanesio
> <[hidden email]> 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 [hidden email].
> 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 [hidden email].
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 | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio
In reply to this post by Luca Milanesio
Hi Manuel,
I discussed the topic with Robert at the Jenkins World conference last week, and we agreed that:

1. More work is needed on the branch discovery side: I need to flag the ones coming from Gerrit Changes with a specific label
2. The plugin is going to be focused on the branch source API feature: Gerrit-branch-source similarly to GitHub-branch-source
3. Gerrit Trigger plugin will stay anyway for his specific use-case: triggering the build based on a Gerrit stream event

Does that answer your questions?

Luca.

On 7 Sep 2017, at 08:08, Vacelet, Manuel <[hidden email]> wrote:

Hi Luca,

Jenkins World Conference is over, did you manage to showcase this new plugin ?
What's the status and what are the plans for the future ?

Manuel

On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio <[hidden email]> wrote:
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."
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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1F0734FE-41C5-4CE1-B88C-E630986C13A6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

Luca Milanesio

On 7 Sep 2017, at 14:48, Vacelet, Manuel <[hidden email]> wrote:

Hi Luca (congrats to the new gerrit maintainer BTW),

It does answer the question but raise a new one ;)
Have you an ETA in mind for all this ?

We are talking about weeks for sure, as I want to ship something fully documented and working.

I was planning to share it as "showcase" with a Docker compose containing:
- Gerrit 2.15 (or a pre-release)
- Jenkins 2.x with BlueOcean

I believe the coupling of BlueOcean + PolyGerrit will give the "business case" for many people to start adopting the two tools instead of heading to GitLab or similar.

Luca.


Manuel
 

On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio <[hidden email]> wrote:
Hi Manuel,
I discussed the topic with Robert at the Jenkins World conference last week, and we agreed that:

1. More work is needed on the branch discovery side: I need to flag the ones coming from Gerrit Changes with a specific label
2. The plugin is going to be focused on the branch source API feature: Gerrit-branch-source similarly to GitHub-branch-source
3. Gerrit Trigger plugin will stay anyway for his specific use-case: triggering the build based on a Gerrit stream event

Does that answer your questions?

Luca.

On 7 Sep 2017, at 08:08, Vacelet, Manuel <[hidden email]> wrote:

Hi Luca,

Jenkins World Conference is over, did you manage to showcase this new plugin ?
What's the status and what are the plans for the future ?

Manuel

On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio <[hidden email]> wrote:
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."
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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/67524463-9EDF-490D-A92C-D9DA03B2B3A3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

stephenconnolly
I recommend using the gitea plugin as a "clean" example of a branch source, as it is relatively feature complete (gaps are api gaps in gitea itself) and free of the rate limit and class migration noise in github and Bitbucket branch source plugins 

On Thu 7 Sep 2017 at 23:00, Luca Milanesio <[hidden email]> wrote:

On 7 Sep 2017, at 14:48, Vacelet, Manuel <[hidden email]> wrote:

Hi Luca (congrats to the new gerrit maintainer BTW),

It does answer the question but raise a new one ;)
Have you an ETA in mind for all this ?

We are talking about weeks for sure, as I want to ship something fully documented and working.

I was planning to share it as "showcase" with a Docker compose containing:
- Gerrit 2.15 (or a pre-release)
- Jenkins 2.x with BlueOcean

I believe the coupling of BlueOcean + PolyGerrit will give the "business case" for many people to start adopting the two tools instead of heading to GitLab or similar.

Luca.


Manuel
 

On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio <[hidden email]> wrote:
Hi Manuel,
I discussed the topic with Robert at the Jenkins World conference last week, and we agreed that:

1. More work is needed on the branch discovery side: I need to flag the ones coming from Gerrit Changes with a specific label
2. The plugin is going to be focused on the branch source API feature: Gerrit-branch-source similarly to GitHub-branch-source
3. Gerrit Trigger plugin will stay anyway for his specific use-case: triggering the build based on a Gerrit stream event

Does that answer your questions?

Luca.

On 7 Sep 2017, at 08:08, Vacelet, Manuel <[hidden email]> wrote:

Hi Luca,

Jenkins World Conference is over, did you manage to showcase this new plugin ?
What's the status and what are the plans for the future ?

Manuel

On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio <[hidden email]> wrote:
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."
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.



--
--
To unsubscribe, email [hidden email]
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/67524463-9EDF-490D-A92C-D9DA03B2B3A3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Sent from my phone

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMztETjCGSzgxH5Q0m1dtuZZ643Pmff6cK0PXYk%3DTrstNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.