[Announce] Gerrit master with scripting plugin support bundle available for download

[Luca Milanesio]

Hi all,

I am pleased to announce that I have finalised the series of patches for the (2nd attempt) introduction of Scripting Plugins support for Gerrit and a bundled master pre-built WAR file is available for download.

What is the Gerrit scripting plugins support ?

For an overview of what scripting plugins are and how they provide benefit to the Gerrit eco-system, you can replay the slides of my last talk at the Gerrit User Summit @GooglePlex in Mountain View - CA:

http://www.slideshare.net/lucamilanesio/gerrit-code-review-how-to-script-a-plugin-with-scala-and-groovy

Where can I get Gerrit with this new feature ?

The set of changes for the scripting plugins support is currently under review at:

https://gerrit-review.googlesource.com/#/q/status:open+topic:scripting-reloaded

You are welcome to see the changes and provide your feedback / score !!

I have configured a Job on http://ci.gerritforge.com/job/Gerrit-master-scripting/ to automatically fetch and build:

- the latest Gerrit 2.10 snapshot on master

- the Gerrit scripting plugin support patches

- the Scala scripting provider

- the Groovy scripting provider

The output is a Gerrit WAR file containing everything bundled together:

http://ci.gerritforge.com/job/Gerrit-master-scripting/lastSuccessfulBuild/artifact/buck-out/gen/gerrit-scripting.war

How can I install the "Gerrit with scripting plugin" ?

Just download the gerrit-scripting.war and run the init again; during the init phase say 'Y' to the 'groovy-provider' and 'scala-provider' are included in the set of core plugins.

*** Plugins

*** 

Install plugin download-commands version v2.9-rc1-325-g96d0d43 [y/N]? n

Install plugin commit-message-length-validator version v2.9-rc1-325-g96d0d43 [y/N]? n

Install plugin reviewnotes version v2.9-rc1-325-g96d0d43 [y/N]? n

Install plugin groovy-provider version v2.9-rc1-325-g96d0d43 [y/N]? y

Install plugin singleusergroup version v2.9-rc1-325-g96d0d43 [y/N]? n

Install plugin replication version v2.9-rc1-325-g96d0d43 [y/N]? n

Install plugin scala-provider version v2.9-rc1-325-g96d0d43 [y/N]? y

How can I write my first Scala and Groovy scripting plugin ?

Writing a plugin using Scala or Groovy scripting language is very easy: just download the script into the Gerrit /plugins directory ... and you're done !

(no restart, no compile, nothing at all ... it JUST WORKS !)

David Ostrovsky has provided nice examples ready to be used at:

https://github.com/davido/gerrit-scala-plugin

https://github.com/davido/gerrit-groovy-plugin

When are scripting plugins going to be included officially in Gerrit ?

It actually depends on you :-) If you like the feature and provide your feedback / score ... they will hopefully pop-up in Gerrit 2.10 :-)

--- * ---

Luca.

[David Ostrovsky]

Am Mittwoch, 23. April 2014 10:10:42 UTC+2 schrieb lucamilanesio:

Hi all,

I am pleased to announce that I have finalised the series of patches for the (2nd attempt) introduction of Scripting Plugins support for Gerrit and a bundled master pre-built WAR file is available for download.

VRFY+1 ;-)

Works as expected.

It's really nice idea to bundle new plugins in release.war, unless we support installing plugins from different locations out of the box.

It's also nice idea to effectively binary fork Gerrit.

I wonder if we could apply the binary fork pattern for other Gerrit series that are pending for review for years now:

* multi-master

* secure-store

* auth-backend

* inline-edit

 

;-)

When are scripting plugins going to be included officially in Gerrit ?

It actually depends on you :-) If you like the feature and provide your feedback / score

I would argue: it also depends on you ;-)

Recently I had a crazy idea to disallow push changes for contributors, who don't perform review.

The idea is that simple:

Every new contributor would get (say) 5 change-upload points.

That would allow her to upload 5 changes to Gerrit.

Attempt to upload change number 6 would fail with:

"Your change-upload points are empty now, please perform code review to acquire new change-upload points!

And of course Code-Review+1/-1 without any comments is not a valid review ;-)

Every review would be count as 1 change-upload point.

The end line of this feature: Review other folks changes, if you expect your changes to be reviewed ...

[lucamilanesio]

On Thursday, April 24, 2014 8:09:49 AM UTC+1, David Ostrovsky wrote:

Am Mittwoch, 23. April 2014 10:10:42 UTC+2 schrieb lucamilanesio:

Hi all,

I am pleased to announce that I have finalised the series of patches for the (2nd attempt) introduction of Scripting Plugins support for Gerrit and a bundled master pre-built WAR file is available for download.

VRFY+1 ;-)

Works as expected.

:-)

And soon the people on GerritHub.io will be able to upload their own Scripting Plugins to be used for their hosted services.

(the patch is already there but need to define the workflow for the scripts review and approval)

 

It's really nice idea to bundle new plugins in release.war, unless we support installing plugins from different locations out of the box.

It's also nice idea to effectively binary fork Gerrit.

Not really a fork, but just one extra "git pull refs/changes/..." before building.

It allows to both provide a binary preview of experimental features and at the same time to have continuous integration with what's going on master.

It is not a fork in the sense that has not a different history: it's more a "continuous merge" rather than a "fork" ;-)

 

I wonder if we could apply the binary fork pattern for other Gerrit series that are pending for review for years now:

* multi-master

* secure-store

* auth-backend

* inline-edit

I was thinking about making the Job parametric:

- receive a Gerrit topic as parameter

- merge all the commits in the topic

- trigger a build and archive the artifact as Gerrit-master-<topic>

What do you think ?

 

 

;-)

When are scripting plugins going to be included officially in Gerrit ?

It actually depends on you :-) If you like the feature and provide your feedback / score

I would argue: it also depends on you ;-)

Recently I had a crazy idea to disallow push changes for contributors, who don't perform review.

The idea is that simple:

Every new contributor would get (say) 5 change-upload points.

That would allow her to upload 5 changes to Gerrit.

Attempt to upload change number 6 would fail with:

"Your change-upload points are empty now, please perform code review to acquire new change-upload points!

And of course Code-Review+1/-1 without any comments is not a valid review ;-)

Every review would be count as 1 change-upload point.

The end line of this feature: Review other folks changes, if you expect your changes to be reviewed ...

That seems a good idea :-)

Luca.

[Luca Milanesio]

On 26 Apr 2014, at 08:53, lucamilanesio <luca.mi...@gmail.com> wrote:

 

I wonder if we could apply the binary fork pattern for other Gerrit series that are pending for review for years now:

* multi-master

* secure-store

* auth-backend

* inline-edit

I was thinking about making the Job parametric:

- receive a Gerrit topic as parameter

- merge all the commits in the topic

- trigger a build and archive the artifact as Gerrit-master-<topic>

I may actually create a Jenkins plugin for this :-)

It may be called "Gerrit topic builder": it could be used as well for providing product builds for early-QA on WIP Gerrit topics.

Luca.

[Dariusz Luksza]

On 04/26/2014 09:53 AM, lucamilanesio wrote:
> It is not a fork in the sense that has not a different history: it's more a "continuous merge" rather than a "fork" ;-)
>
>
> I wonder if we could apply the binary fork pattern for other Gerrit series that are pending for review for years now:
>
> * multi-master
> * secure-store
> * auth-backend
> * inline-edit
>
>
> I was thinking about making the Job parametric:
> - receive a Gerrit topic as parameter
> - merge all the commits in the topic
> - trigger a build and archive the artifact as Gerrit-master-<topic>
>
> What do you think ?
>

I have mixed filing about this idea. From one hand will make testing easier, since one don't need to set up dev environment and build gerrit on his own. The main question here is how many people would
test such builds? Having them only for purpose of having them is giving us nothing.

From the other, this could make some confusion and since people culd run 'forks' and will refer to them as vanilla Gerrit. Also continuous rebasing is really painful.

IMO we should push those changes to be merged in master, not create "workarounds" to have forked binaries with requested features.

--
Best regards

Twitter: @dluksza
GSM: +49 017 445 41235
Blog: http://luksza.org http://javablog.pl
LinkedIn: http://linkedin.com/in/dariuszluksza

[David Ostrovsky]

Hah ! I had the same idea and wanted to propose it here but you was faster ;-)

So the idea would be to set up parametrized Jenkins build [1], where the parameters are Fxperimental Feature (or Topics):

EF_1, ..., EF_n. That way we don't need to create all permutations jobs of n experimental topics/features.

So we need two dimensions of parameters: experimental topics/features + bundled plugins:

Dimension 1: Which experimental features should be included in the binary artifacts.

Dimension 2: Which plugins should be bundled into gerrit.war, to make plugin installation a trivial task.

Example: Topic, Plugin:

* scripting-reloaded, Plugins: groovy-provider, scala-provider

* secure-store, Plugin: secure-store-provider-plugin

* auth-backend, Plugin: different auth-backend-providers

* multi-master, Plugin: websession-flatfile

* inline-edit, Plugin: change-fabricator-plugin

But I think, it would make only sense to grant the ACL for registered users on your Jenkins to generate custom artifacts, right?

IOW for paying customers ;-)

In any event you could just add hard coded Job with all experimental features + all plugins ;-)

[1] https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build

[David Ostrovsky]

Am Samstag, 26. April 2014 09:59:36 UTC+2 schrieb lucamilanesio:

On 26 Apr 2014, at 08:53, lucamilanesio <luca.mi...@gmail.com> wrote:

 

I wonder if we could apply the binary fork pattern for other Gerrit series that are pending for review for years now:

* multi-master

* secure-store

* auth-backend

* inline-edit

I was thinking about making the Job parametric:

- receive a Gerrit topic as parameter

- merge all the commits in the topic

- trigger a build and archive the artifact as Gerrit-master-<topic>

I may actually create a Jenkins plugin for this :-)

 As much as I like the idea, i think right tool for the job would be to write Jenkins plugin, and not Gerrit plugin:

Gerrit-custom-bundler

Or just do it with vanilla Jenkins.

[Luca Milanesio]

On 26 Apr 2014, at 10:44, Dariusz Luksza <dariusz...@gmail.com> wrote:
>
> I have mixed filing about this idea. From one hand will make testing easier, since one don't need to set up dev environment and build gerrit on his own. The main question here is how many people would test such builds? Having them only for purpose of having them is giving us nothing.

There are two type of people that are benefiting from those builds:
a) Yourself: I typically don't trust builds on my local dev environment. Things always work locally (or at least should work). Having a CI of your topics is always useful :-)
b) Others (reviewers or not): looking at the code + having it working "out-of-the-box" help judging if that feature makes sense or not.

>
> From the other, this could make some confusion and since people culd run 'forks' and will refer to them as vanilla Gerrit. Also continuous rebasing is really painful.

It's not a fork but a continuous merge + build. It is really useful to understand *IF* your topic is still working if merged with master or not.

>
> IMO we should push those changes to be merged in master, not create "workarounds" to have forked binaries with requested features.

Yes, we are ... and having something working and demonstrate that the feature makes sense and works ... is always a good reason for encouraging a +1 :-)
At the end of the day, if merges to master and works fine ... is already a Verified +1 :-) So one first step to get it merged.

Luca.

[David Ostrovsky]

Am Samstag, 26. April 2014 16:00:29 UTC+2 schrieb lucamilanesio:

On 26 Apr 2014, at 10:44, Dariusz Luksza <dariusz...@gmail.com> wrote:
>
> I have mixed filing about this idea. From one hand will make testing easier, since one don't need to set up dev environment and build gerrit on his own. The main question here is how many people would test such builds? Having them only for purpose of having them is giving us nothing.

There are two type of people that are benefiting from those builds:
a) Yourself: I typically don't trust builds on my local dev environment. Things always work locally (or at least should work). Having a CI of your topics is always useful :-)
b) Others (reviewers or not): looking at the code + having it working "out-of-the-box" help judging if that feature makes sense or not.

c) Deploy Gerrit with experimental feature(s) on some staging (cloud) publicly available

instance to test/review/play for non developer.

See the situation with inline-edit series: I think folks out there really want this feature.

Nowadays (with Buck) it takes ca. 2 min. on my laptop to pull the series, compile and start it -

no database upgrade is needed.

Given that the series was already rewritten 4 times and can be tested for 1 year now,

only three people tested it and provided feedback.

I think, if custom Gerrit build with this feature is available on gerrit-review-dev, or gerrithub.io, or ...

it would lower the barrier for test/feedback/review.

>
> From the other, this could make some confusion and since people culd run 'forks' and will refer to them as vanilla Gerrit. Also continuous rebasing is really painful.

It's not a fork but a continuous merge + build. It is really useful to understand *IF* your topic is still working if merged with master or not.

>
> IMO we should push those changes to be merged in master, not create "workarounds" to have forked binaries with requested features.

Yes, we are ... and having something working and demonstrate that the feature makes sense and works ... is always a good reason for encouraging a +1 :-)
At the end of the day, if merges to master and works fine ... is already a Verified +1 :-) So one first step to get it merged.

+1

And we would mark the "continuous merge" binaries with "don't try it at home" warning ;-)

"Include not appoved, experimental features. Not recommended for production use."

[Luca Milanesio]

Good idea for the inline-edit series: will define the job and share for allowing other people to experiment the inline-edit.

At the end of the day, OpenSource is sharing and getting early feedback.

P.S. There is a new repos for the ci jobs DSL, will push all the configs there so that anyone can define extra jobs.

Luca.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
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 repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dariusz Luksza]

On 04/26/2014 04:00 PM, Luca Milanesio wrote:
>>
>> IMO we should push those changes to be merged in master, not create "workarounds" to have forked binaries with requested features.
>
> Yes, we are ... and having something working and demonstrate that the feature makes sense and works ... is always a good reason for encouraging a +1 :-)
> At the end of the day, if merges to master and works fine ... is already a Verified +1 :-) So one first step to get it merged.

Even if your patch has five or then +1 it doesn't really mean that it will be merged soon. We should rather ask maintainers if such build would improve theirs workflow, at the end of the day they have
rights to +2 and submit.

Having topic build would be a nice feature, but don't think that this will improve new features mergebility... hope it would

[lucamilanesio]

Job available and built successfully at:

http://ci.gerritforge.com/job/Gerrit-master-inline-edit/

Please do a sanity check before announce it :-)

Luca.

[David Ostrovsky]

Am Samstag, 26. April 2014 23:51:33 UTC+2 schrieb lucamilanesio:

Job available and built successfully at:

http://ci.gerritforge.com/job/Gerrit-master-inline-edit/

Please do a sanity check before announce it :-)

Thank you, works as expected ;-)

Your help is very much appreciated.

But, to support 100% browser workflow change-fabricator-plugin [1] or

topic to de-externalize it [2] need to be included in the war.

I think another topic to include into war is simpler and less noise during installation.

Another question: You said you have installed scripting-reloaded series on gerrithub.io.

Would it be an option to install inline-edit + create-change-action series on gerrithub.io too?

[1] https://github.com/davido/gerrit-change-fabricator

[2] https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:create-change-action

[Luca Milanesio]

On 28 Apr 2014, at 10:37, David Ostrovsky <david.o...@gmail.com> wrote:

Am Samstag, 26. April 2014 23:51:33 UTC+2 schrieb lucamilanesio:

Job available and built successfully at:

http://ci.gerritforge.com/job/Gerrit-master-inline-edit/

Please do a sanity check before announce it :-)

Thank you, works as expected ;-)

Your help is very much appreciated.

But, to support 100% browser workflow change-fabricator-plugin [1] or

topic to de-externalize it [2] need to be included in the war.

OK, will amend the job with those.

I think another topic to include into war is simpler and less noise during installation.

Another question: You said you have installed scripting-reloaded series on gerrithub.io.

Would it be an option to install inline-edit + create-change-action series on gerrithub.io too?

Will upload first to staging (staging.gerrithub.io) and when it is stable will roll it out.

In-line edit is a cool feature, for sure people would like it :-)

GerritHub.io is for experimenting and sharing feedback, so seems to be the perfect place for showcasing it.

Luca.

[1] https://github.com/davido/gerrit-change-fabricator

[2] https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit+branch:master+topic:create-change-action

[David Ostrovsky]

Am Montag, 28. April 2014 12:26:33 UTC+2 schrieb lucamilanesio:

On 28 Apr 2014, at 10:37, David Ostrovsky <david.o...@gmail.com> wrote:

Am Samstag, 26. April 2014 23:51:33 UTC+2 schrieb lucamilanesio:

Job available and built successfully at:

http://ci.gerritforge.com/job/Gerrit-master-inline-edit/

Please do a sanity check before announce it :-)

Thank you, works as expected ;-)

Your help is very much appreciated.

But, to support 100% browser workflow change-fabricator-plugin [1] or

topic to de-externalize it [2] need to be included in the war.

OK, will amend the job with those.

I think another topic to include into war is simpler and less noise during installation.

Another question: You said you have installed scripting-reloaded series on gerrithub.io.

Would it be an option to install inline-edit + create-change-action series on gerrithub.io too?

Will upload first to staging (staging.gerrithub.io) and when it is stable will roll it out.

In-line edit is a cool feature, for sure people would like it :-)

That's cool ;-) I have never tried gerrithub.io.

It's time to change.

[lucamilanesio]

Hi all,

I am very pleased to announce that the Gerrit scripting support has been merged on Gerrit master and will then be part of the next forthcoming Gerrit Ver. 2.10 release.

I would like to give a very warm THANK YOU to all the people that reviewed and contributed to the merge of this topic: it has been a great Team effort, thanks again.

I have then removed the Gerrit-scripting job on ci.gerritforge.com as it is not needed anymore.

See below then the amended instructions on how to get started with the Gerrit scripting plugins.

What is the Gerrit scripting plugins support ?

For an overview of what scripting plugins are and how they provide benefit to the Gerrit eco-system, you can replay the slides of my last talk at the Gerrit User Summit @GooglePlex in Mountain View - CA:

http://www.slideshare.net/lucamilanesio/gerrit-code-review-how-to-script-a-plugin-with-scala-and-groovy

Where can I get Gerrit with this new feature ?

Just clone and build Gerrit master branch or alternatively download the latest CI build from:

http://ci.gerritforge.com/job/Gerrit-master/lastSuccessfulBuild/artifact/buck-out/gen/release.war

 

How can I install the "Gerrit with scripting plugin" ?

Just download the scripting providers you want to use (groovy-provider and scala-provider are the ones developed so far) and put the JAR files to the $GERRIT_SITE/plugins directory.

Groovy Scripting Provider.

Clone and build form source:

git clone https://gerrit.googlesource.com/plugins/scripting/groovy-provider

or download the latest master CI build:

http://ci.gerritforge.com/view/Plugins-master/job/Plugin_scripting-groovy-provider_master/lastSuccessfulBuild/artifact/groovy-provider.jar

 

Scala Scripting Provider.

Clone and build form source:

git clone https://gerrit.googlesource.com/plugins/scripting/scala-provider

or download the latest master CI build:

http://ci.gerritforge.com/view/Plugins-master/job/Plugin_scripting-scala-provider_master/lastSuccessfulBuild/artifact/scala-provider.jar

How can I write my first Scala and Groovy scripting plugin ?

Writing a plugin using Scala or Groovy scripting language is very easy: just download the script into the Gerrit /plugins directory ... and you're done !

(no restart, no compile, nothing at all ... it JUST WORKS !)

David Ostrovsky has provided nice examples ready to be used at:

https://github.com/davido/gerrit-scala-plugin

https://github.com/davido/gerrit-groovy-plugin

When are scripting plugins going to be included officially in Gerrit ?

YEAH ! Gerrit 2.10 will include support for pluggable scripting engines, including Groovy and Scala.

You will be even free to implement the support for your own favourite scripting langauge ... or invent a new one. 

The cookbook plugin (https://gerrit.googlesource.com/plugins/cookbook-plugin) has been amended to include a sample for this.

Luca.

[David Ostrovsky]

Am Donnerstag, 3. Juli 2014 13:16:55 UTC+2 schrieb lucamilanesio:

Hi all,

I am very pleased to announce that the Gerrit scripting support has been merged on Gerrit master and will then be part of the next forthcoming Gerrit Ver. 2.10 release.

I would like to give a very warm THANK YOU to all the people that reviewed and contributed to the merge of this topic: it has been a great Team effort, thanks again.

Well done, Luca! You broke even a record with this change [1]:

it's the first one, that has 46 patch sets and was merged.

I don't know how you did that review/merge trick with scripting-plugin series,

but can't you apply the same trick on Online Edit series too [2]?

;-)

[1] https://gerrit-review.googlesource.com/56098

[2] https://code.google.com/p/gerrit/wiki/OutstandingTopics#On-Line_edit

[Luca Milanesio]

Well done David as well, your help with the reviews was really useful.

(you contributed as well to my 46-patch-sets record)

I will be more than happy to help out with the reviews of the other outstanding topics, including on-line edit and authentication backends.

Luca.