We would like to contribute a new Gerrit-plugin!

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

We would like to contribute a new Gerrit-plugin!

GLundh
Hi, all Hudson fans!

Last year, we started working on a Gerrit-Hudson plugin (for building pre-commits/uploads to gerrit).

The development on this plugin was low/halted for quite a while, but now we have kick-started the development again.

We like the progress we are seeing and the new features and we really want to contribute this plugin back to the community. But we can also see that a Gerrit plugin already exists. So we are not sure on the best approach to donate this plugin to the community.

Before continuing the discussion regarding contributing the plugin, let us present our Hudson-Gerrit approach and the differences with the already existing Gerrit-plugin.

1. Our plugin relies on the Gerrit event-stream. E.g. it does not pull information from the server, but it listens to the newly implemented Gerrit event ssh-stream for changes. This will make it easier to scale for enterprise purposes. Hundreds of GITs can be monitored without risk for wasting cycles polling the Gerrit-server. It also means that projects are triggered in the exact same second that the upload is being made.

2. Global configuration

We have a global configuration screen for server-configuration:



[global.png]

 
This link directs to this page:



[global2.png]


This helps the users being able to setup projects themselves without knowing all details about .ssh-key paths etc. Here you also setup good default +1/-1 values for the reviews.

If you press the advanced button you can customize the actual messages:



[globaladvanced.png]


3. Project configuration

On the project page we get this configuration:



[project.png]


Since all server-settings is configured globally, the only thing the user needs to define, is which GITs and branches he/she wants to monitor.

So for instance, one Hudson-project can listen and build on multiple GITs and branches.

But! If many projects listens on the same GIT/branch, all of them will be triggered, but the result will not be reported back in Gerrit until all projects are done building. Yes, it is that awesome ;)

A typical review by Hudson looks like this, but it is of course fully customizable:



[review.png]


If you want, you can click ‘Advanced’ to override certain global report settings (empty means: “not override”):



[projectadvanced.png]


We have taken quite a different approach compared to the existing Gerrit->Hudson integration. As stated in the beginning of this post, we want to contribute the plugin to the community, but not sure on how to approach this situation, where there are already a fine and working, but vastly different, plugin available.

We think it will be hard to merge the changes (different approach and architecture). But we also understand it can be counterproductive to have two different but similar projects. Should we hold off the contribution? Contribute? Ideas and suggestions please.

Best regards
Robert and Gustaf
Sony Ericsson
Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Andrew Bayer
I think there are enough differences here that yeah, the code bases probably can't be easily reconciled. But at the very least, I'd definitely be interested in seeing your plugin - the workflow you describe sounds like it might fit my use case better than the existing gerrit plugin. I think it's definitely worth talking with Jyrki (the writer of the original gerrit plugin) to see if there's a way for you guys to work together to see if you can come up with a plugin that combines your efforts, but if that doesn't pan out, I don't see any problem with having two plugins covering two different use cases/workflows for the same tools.

A.

On Thu, May 20, 2010 at 10:09 AM, GLundh <[hidden email]> wrote:

Hi, all Hudson fans!

Last year, we started working on a Gerrit-Hudson plugin (for building
pre-commits/uploads to gerrit).

The development on this plugin was low/halted for quite a while, but now we
have kick-started the development again.

We like the progress we are seeing and the new features and we really want
to contribute this plugin back to the community. But we can also see that a
Gerrit plugin already exists. So we are not sure on the best approach to
donate this plugin to the community.

Before continuing the discussion regarding contributing the plugin, let us
present our Hudson-Gerrit approach and the differences with the already
existing Gerrit-plugin.

1. Our plugin relies on the Gerrit event-stream. E.g. it does not pull
information from the server, but it listens to the newly implemented Gerrit
event ssh-stream for changes. This will make it easier to scale for
enterprise purposes. Hundreds of GITs can be monitored without risk for
wasting cycles polling the Gerrit-server. It also means that projects are
triggered in the exact same second that the upload is being made.

2. Global configuration

We have a global configuration screen for server-configuration:


http://n4.nabble.com/file/n2224606/global.png
[global.png]


This link directs to this page:


http://n4.nabble.com/file/n2224606/global2.png
[global2.png]


This helps the users being able to setup projects themselves without knowing
all details about .ssh-key paths etc. Here you also setup good default +1/-1
values for the reviews.

If you press the advanced button you can customize the actual messages:


http://n4.nabble.com/file/n2224606/globaladvanced.png
[globaladvanced.png]


3. Project configuration

On the project page we get this configuration:


http://n4.nabble.com/file/n2224606/project.png
[project.png]


Since all server-settings is configured globally, the only thing the user
needs to define, is which GITs and branches he/she wants to monitor.

So for instance, one Hudson-project can listen and build on multiple GITs
and branches.

But! If many projects listens on the same GIT/branch, all of them will be
triggered, but the result will not be reported back in Gerrit until all
projects are done building. Yes, it is that awesome ;)

A typical review by Hudson looks like this, but it is of course fully
customizable:


http://n4.nabble.com/file/n2224606/review.png
[review.png]


If you want, you can click ‘Advanced’ to override certain global report
settings (empty means: “not override”):


http://n4.nabble.com/file/n2224606/projectadvanced.png
[projectadvanced.png]


We have taken quite a different approach compared to the existing
Gerrit->Hudson integration. As stated in the beginning of this post, we want
to contribute the plugin to the community, but not sure on how to approach
this situation, where there are already a fine and working, but vastly
different, plugin available.

We think it will be hard to merge the changes (different approach and
architecture). But we also understand it can be counterproductive to have
two different but similar projects. Should we hold off the contribution?
Contribute? Ideas and suggestions please.

Best regards
Robert and Gustaf
Sony Ericsson

--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2224606.html
Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Jyrki Puttonen
In reply to this post by GLundh
Hi all,

It seems that you have a lot better plugin for Gerrit :) The version I did only reports errors to Gerrit, actual polling is done by Git -plugin. I have one question about stream-events, though. What happens if stream connection is lost and there's new change sets in Gerrit before the connection comes back up? I've been thinking about using stream-events for current plugin, but haven't got anything done yet about that.

I also agree that it would be hard to merge these changes, and it would be waste to have two similar plugins. My opinion is that we should use what you've done, it just seems to be better.

On May 20, 2010, at 5:09 PM, GLundh wrote:

>
> Hi, all Hudson fans!
>
> Last year, we started working on a Gerrit-Hudson plugin (for building
> pre-commits/uploads to gerrit).
>
> The development on this plugin was low/halted for quite a while, but now we
> have kick-started the development again.
>
> We like the progress we are seeing and the new features and we really want
> to contribute this plugin back to the community. But we can also see that a
> Gerrit plugin already exists. So we are not sure on the best approach to
> donate this plugin to the community.
>
> Before continuing the discussion regarding contributing the plugin, let us
> present our Hudson-Gerrit approach and the differences with the already
> existing Gerrit-plugin.
>
> 1. Our plugin relies on the Gerrit event-stream. E.g. it does not pull
> information from the server, but it listens to the newly implemented Gerrit
> event ssh-stream for changes. This will make it easier to scale for
> enterprise purposes. Hundreds of GITs can be monitored without risk for
> wasting cycles polling the Gerrit-server. It also means that projects are
> triggered in the exact same second that the upload is being made.
>
> 2. Global configuration
>
> We have a global configuration screen for server-configuration:
>
>
> http://n4.nabble.com/file/n2224606/global.png 
> [global.png]
>
>
> This link directs to this page:
>
>
> http://n4.nabble.com/file/n2224606/global2.png 
> [global2.png]
>
>
> This helps the users being able to setup projects themselves without knowing
> all details about .ssh-key paths etc. Here you also setup good default +1/-1
> values for the reviews.
>
> If you press the advanced button you can customize the actual messages:
>
>
> http://n4.nabble.com/file/n2224606/globaladvanced.png 
> [globaladvanced.png]
>
>
> 3. Project configuration
>
> On the project page we get this configuration:
>
>
> http://n4.nabble.com/file/n2224606/project.png 
> [project.png]
>
>
> Since all server-settings is configured globally, the only thing the user
> needs to define, is which GITs and branches he/she wants to monitor.
>
> So for instance, one Hudson-project can listen and build on multiple GITs
> and branches.
>
> But! If many projects listens on the same GIT/branch, all of them will be
> triggered, but the result will not be reported back in Gerrit until all
> projects are done building. Yes, it is that awesome ;)
>
> A typical review by Hudson looks like this, but it is of course fully
> customizable:
>
>
> http://n4.nabble.com/file/n2224606/review.png 
> [review.png]
>
>
> If you want, you can click ‘Advanced’ to override certain global report
> settings (empty means: “not override”):
>
>
> http://n4.nabble.com/file/n2224606/projectadvanced.png 
> [projectadvanced.png]
>
>
> We have taken quite a different approach compared to the existing
> Gerrit->Hudson integration. As stated in the beginning of this post, we want
> to contribute the plugin to the community, but not sure on how to approach
> this situation, where there are already a fine and working, but vastly
> different, plugin available.
>
> We think it will be hard to merge the changes (different approach and
> architecture). But we also understand it can be counterproductive to have
> two different but similar projects. Should we hold off the contribution?
> Contribute? Ideas and suggestions please.
>
> Best regards
> Robert and Gustaf
> Sony Ericsson
>
> --
> View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2224606.html
> Sent from the Hudson dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: We would like to contribute a new Gerrit-plugin!

Sandell, Robert
Hi,
You are correct in pointing out the problem when the connection is lost.
One solution that we have been thinking about is to implement an event buffer in Gerrit, so when the connection comes back up the waiting events gets sent directly upon connection.


BR
Robert and Gustaf
Sony Ericsson

-----Original Message-----
From: Jyrki Puttonen [mailto:[hidden email]]
Sent: den 20 maj 2010 18:21
To: [hidden email]
Subject: Re: We would like to contribute a new Gerrit-plugin!

Hi all,

It seems that you have a lot better plugin for Gerrit :) The version I did only reports errors to Gerrit, actual polling is done by Git -plugin. I have one question about stream-events, though. What happens if stream connection is lost and there's new change sets in Gerrit before the connection comes back up? I've been thinking about using stream-events for current plugin, but haven't got anything done yet about that.

I also agree that it would be hard to merge these changes, and it would be waste to have two similar plugins. My opinion is that we should use what you've done, it just seems to be better.

On May 20, 2010, at 5:09 PM, GLundh wrote:

>
> Hi, all Hudson fans!
>
> Last year, we started working on a Gerrit-Hudson plugin (for building
> pre-commits/uploads to gerrit).
>
> The development on this plugin was low/halted for quite a while, but now we
> have kick-started the development again.
>
> We like the progress we are seeing and the new features and we really want
> to contribute this plugin back to the community. But we can also see that a
> Gerrit plugin already exists. So we are not sure on the best approach to
> donate this plugin to the community.
>
> Before continuing the discussion regarding contributing the plugin, let us
> present our Hudson-Gerrit approach and the differences with the already
> existing Gerrit-plugin.
>
> 1. Our plugin relies on the Gerrit event-stream. E.g. it does not pull
> information from the server, but it listens to the newly implemented Gerrit
> event ssh-stream for changes. This will make it easier to scale for
> enterprise purposes. Hundreds of GITs can be monitored without risk for
> wasting cycles polling the Gerrit-server. It also means that projects are
> triggered in the exact same second that the upload is being made.
>
> 2. Global configuration
>
> We have a global configuration screen for server-configuration:
>
>
> http://n4.nabble.com/file/n2224606/global.png 
> [global.png]
>
>
> This link directs to this page:
>
>
> http://n4.nabble.com/file/n2224606/global2.png 
> [global2.png]
>
>
> This helps the users being able to setup projects themselves without knowing
> all details about .ssh-key paths etc. Here you also setup good default +1/-1
> values for the reviews.
>
> If you press the advanced button you can customize the actual messages:
>
>
> http://n4.nabble.com/file/n2224606/globaladvanced.png 
> [globaladvanced.png]
>
>
> 3. Project configuration
>
> On the project page we get this configuration:
>
>
> http://n4.nabble.com/file/n2224606/project.png 
> [project.png]
>
>
> Since all server-settings is configured globally, the only thing the user
> needs to define, is which GITs and branches he/she wants to monitor.
>
> So for instance, one Hudson-project can listen and build on multiple GITs
> and branches.
>
> But! If many projects listens on the same GIT/branch, all of them will be
> triggered, but the result will not be reported back in Gerrit until all
> projects are done building. Yes, it is that awesome ;)
>
> A typical review by Hudson looks like this, but it is of course fully
> customizable:
>
>
> http://n4.nabble.com/file/n2224606/review.png 
> [review.png]
>
>
> If you want, you can click 'Advanced' to override certain global report
> settings (empty means: "not override"):
>
>
> http://n4.nabble.com/file/n2224606/projectadvanced.png 
> [projectadvanced.png]
>
>
> We have taken quite a different approach compared to the existing
> Gerrit->Hudson integration. As stated in the beginning of this post, we want
> to contribute the plugin to the community, but not sure on how to approach
> this situation, where there are already a fine and working, but vastly
> different, plugin available.
>
> We think it will be hard to merge the changes (different approach and
> architecture). But we also understand it can be counterproductive to have
> two different but similar projects. Should we hold off the contribution?
> Contribute? Ideas and suggestions please.
>
> Best regards
> Robert and Gustaf
> Sony Ericsson
>
> --
> View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2224606.html
> Sent from the Hudson dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Jyrki Puttonen
Great to hear that.

But for now, would it be possible to use the current approach (Git plugin polling Gerrit) as an option for stream-events and then use what you have for reporting? That would fix also a problem that comes when you are using multiple different Gerrit instances.

Both of these problems (connection loss and multiple Gerrit instances) won't probably affect in enterprise level (or perhaps they aren't issues at all), but they might have affect when you've got loose community (i.e. some open source projects) where Gerrit and Hudson servers aren't in same location and/or one Hudson instance might be used with multiple Gerrit instances.

For my personal and work related use cases, stream events would probably work perfectly.

As for how we could make the change of plugin, one possibility would be make a deleting commit to http://github.com/hudson/Hudson-Gerrit-Plugin and do something like http://stackoverflow.com/questions/277029/combining-multiple-git-repositories (I'm assuming that you are using Git :)). Or if there's no need to keep your history, it would be a lot more simpler. Of course, if there's other ways to do this, I'm perfectly ok for using those.

On May 20, 2010, at 7:50 PM, Sandell, Robert wrote:

> Hi,
> You are correct in pointing out the problem when the connection is lost.
> One solution that we have been thinking about is to implement an event buffer in Gerrit, so when the connection comes back up the waiting events gets sent directly upon connection.
>
>
> BR
> Robert and Gustaf
> Sony Ericsson
>
> -----Original Message-----
> From: Jyrki Puttonen [mailto:[hidden email]]
> Sent: den 20 maj 2010 18:21
> To: [hidden email]
> Subject: Re: We would like to contribute a new Gerrit-plugin!
>
> Hi all,
>
> It seems that you have a lot better plugin for Gerrit :) The version I did only reports errors to Gerrit, actual polling is done by Git -plugin. I have one question about stream-events, though. What happens if stream connection is lost and there's new change sets in Gerrit before the connection comes back up? I've been thinking about using stream-events for current plugin, but haven't got anything done yet about that.
>
> I also agree that it would be hard to merge these changes, and it would be waste to have two similar plugins. My opinion is that we should use what you've done, it just seems to be better.
>
> On May 20, 2010, at 5:09 PM, GLundh wrote:
>
>>
>> Hi, all Hudson fans!
>>
>> Last year, we started working on a Gerrit-Hudson plugin (for building
>> pre-commits/uploads to gerrit).
>>
>> The development on this plugin was low/halted for quite a while, but now we
>> have kick-started the development again.
>>
>> We like the progress we are seeing and the new features and we really want
>> to contribute this plugin back to the community. But we can also see that a
>> Gerrit plugin already exists. So we are not sure on the best approach to
>> donate this plugin to the community.
>>
>> Before continuing the discussion regarding contributing the plugin, let us
>> present our Hudson-Gerrit approach and the differences with the already
>> existing Gerrit-plugin.
>>
>> 1. Our plugin relies on the Gerrit event-stream. E.g. it does not pull
>> information from the server, but it listens to the newly implemented Gerrit
>> event ssh-stream for changes. This will make it easier to scale for
>> enterprise purposes. Hundreds of GITs can be monitored without risk for
>> wasting cycles polling the Gerrit-server. It also means that projects are
>> triggered in the exact same second that the upload is being made.
>>
>> 2. Global configuration
>>
>> We have a global configuration screen for server-configuration:
>>
>>
>> http://n4.nabble.com/file/n2224606/global.png 
>> [global.png]
>>
>>
>> This link directs to this page:
>>
>>
>> http://n4.nabble.com/file/n2224606/global2.png 
>> [global2.png]
>>
>>
>> This helps the users being able to setup projects themselves without knowing
>> all details about .ssh-key paths etc. Here you also setup good default +1/-1
>> values for the reviews.
>>
>> If you press the advanced button you can customize the actual messages:
>>
>>
>> http://n4.nabble.com/file/n2224606/globaladvanced.png 
>> [globaladvanced.png]
>>
>>
>> 3. Project configuration
>>
>> On the project page we get this configuration:
>>
>>
>> http://n4.nabble.com/file/n2224606/project.png 
>> [project.png]
>>
>>
>> Since all server-settings is configured globally, the only thing the user
>> needs to define, is which GITs and branches he/she wants to monitor.
>>
>> So for instance, one Hudson-project can listen and build on multiple GITs
>> and branches.
>>
>> But! If many projects listens on the same GIT/branch, all of them will be
>> triggered, but the result will not be reported back in Gerrit until all
>> projects are done building. Yes, it is that awesome ;)
>>
>> A typical review by Hudson looks like this, but it is of course fully
>> customizable:
>>
>>
>> http://n4.nabble.com/file/n2224606/review.png 
>> [review.png]
>>
>>
>> If you want, you can click 'Advanced' to override certain global report
>> settings (empty means: "not override"):
>>
>>
>> http://n4.nabble.com/file/n2224606/projectadvanced.png 
>> [projectadvanced.png]
>>
>>
>> We have taken quite a different approach compared to the existing
>> Gerrit->Hudson integration. As stated in the beginning of this post, we want
>> to contribute the plugin to the community, but not sure on how to approach
>> this situation, where there are already a fine and working, but vastly
>> different, plugin available.
>>
>> We think it will be hard to merge the changes (different approach and
>> architecture). But we also understand it can be counterproductive to have
>> two different but similar projects. Should we hold off the contribution?
>> Contribute? Ideas and suggestions please.
>>
>> Best regards
>> Robert and Gustaf
>> Sony Ericsson
>>
>> --
>> View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2224606.html
>> Sent from the Hudson dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

GLundh
In reply to this post by GLundh
Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In a week/few weeks we will contribute the plug-in as a separate project. If/when the community deems the new plug-in fully covers the functionality of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Kohsuke Kawaguchi
Administrator
Yes. We've done similar things in the past between ivy and ivy2
plugin, I believe.

2010/5/26 GLundh <[hidden email]>:

>
> Hi!
>
> Thanks for your comments!
>
> We are currently finalizing the code and preparing for the contribution. In
> a week/few weeks we will contribute the plug-in as a separate project.
> If/when the community deems the new plug-in fully covers the functionality
> of the old one, we can merge/replace the current one. Is this OK?
>
> Br
> Gustaf & Bobby
> --
> View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html
> Sent from the Hudson dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Andrew Bayer
In reply to this post by GLundh
Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

A.

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:

Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html
Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Andrew Bayer
Hey guys -

Just wanted to check and see what the status of your plugin is - we're really looking forward to it here, since it seems like it'll fit our concurrent build model for pre-tested commits better than the existing plugin. 

A.

On Thu, May 27, 2010 at 11:49 AM, Andrew Bayer <[hidden email]> wrote:
Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

A.

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:

Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html
Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

RE: We would like to contribute a new Gerrit-plugin!

Sandell, Robert

Hi,

 

The status is quite good, I have been doing some testing and finalization the last weeks, and through it works really well on my development machine with a local Gerrit and Hudson installation I haven’t been able to test it on a larger scale in a production like environment yet, so I don’t dare to say that it works until I have put it through some heavy load :)

 

Last week we hit a small bump in the road when we were trying to use it together with the git plugin, so far we have used it with freestyle shell scripts that fetches code, but since you guys really liked our approach I thought that I should make sure that it works well with the git plugin as well.

The problem is that I couldn’t get the GitSCM to fetch an explicit refspec, when the trigger schedules a build it puts an bunch of ParameterValues into a ParameterAction so that, among others, the REFSPEC value from Gerrit is available as an env var. The git plugin can resolve those values correctly if you specify $REFSPEC to the refspec config in the job but the git plugin doesn’t choose the correct id in the refspec to build no matter how I try to configure it.

I’ve solved the problem by implementing yet another “Choosing strategy” in the git plugin that builds FETCH_HEAD, but I’m not proud of that solution, it feels a bit “quick ´n dirty” and it also gives the user the option between “Default”, “Gerrit” and “Gerrit Trigger” which is probably a bit confusing. Does anyone have any better idea?

 

But besides the large scale testing and the git plugin issue we feel quite ready to share, all our internal bureaucracy for code release is also done so there are no problems of that kind left.

 

Perhaps we can upload the code for you guys and any others interested to build and test out (perhaps help with some bugfixing of issues you find) before an official version is built and pushed to the maven repo? I don’t know how it’s normally done, I’m a first time commiter.

On that not I have another question: I’ve seen that the existing Gerrit- and the git-plugin is hosted on GitHub and then periodically pushed into the svn repo, since we like git that would be good (and cool) to do, but I’m not sure if it’s worth the effort. Does anyone have any suggestions on the approach on this?

 

Hope to release soon.

BR

Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 7 juni 2010 22:05
To: [hidden email]
Subject: Re: We would like to contribute a new Gerrit-plugin!

 

Hey guys -

 

Just wanted to check and see what the status of your plugin is - we're really looking forward to it here, since it seems like it'll fit our concurrent build model for pre-tested commits better than the existing plugin. 

 

A.

On Thu, May 27, 2010 at 11:49 AM, Andrew Bayer <[hidden email]> wrote:

Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

 

A.

 

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:


Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html

Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

 

 

Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Andrew Bayer
I think the choosing strategy is probably the best approach - I believe Jyrki did some work on the git plugin to make the choosing strategy extensible, so that you'd define your choosing strategy in your plugin, not in the git plugin, but I'm not sure what ended up happening with that.

And yes, GitHub is fine - just let us know the github usernames for any users you want to have push permission to the GitHub repo and we can get it set up under github.com/hudson. You'll also want to get java.net accounts and let us know those as well, so that you can have write access to the SVN repo and the Maven repo.

A.

On Tue, Jun 8, 2010 at 7:52 PM, Sandell, Robert <[hidden email]> wrote:

Hi,

 

The status is quite good, I have been doing some testing and finalization the last weeks, and through it works really well on my development machine with a local Gerrit and Hudson installation I haven’t been able to test it on a larger scale in a production like environment yet, so I don’t dare to say that it works until I have put it through some heavy load :)

 

Last week we hit a small bump in the road when we were trying to use it together with the git plugin, so far we have used it with freestyle shell scripts that fetches code, but since you guys really liked our approach I thought that I should make sure that it works well with the git plugin as well.

The problem is that I couldn’t get the GitSCM to fetch an explicit refspec, when the trigger schedules a build it puts an bunch of ParameterValues into a ParameterAction so that, among others, the REFSPEC value from Gerrit is available as an env var. The git plugin can resolve those values correctly if you specify $REFSPEC to the refspec config in the job but the git plugin doesn’t choose the correct id in the refspec to build no matter how I try to configure it.

I’ve solved the problem by implementing yet another “Choosing strategy” in the git plugin that builds FETCH_HEAD, but I’m not proud of that solution, it feels a bit “quick ´n dirty” and it also gives the user the option between “Default”, “Gerrit” and “Gerrit Trigger” which is probably a bit confusing. Does anyone have any better idea?

 

But besides the large scale testing and the git plugin issue we feel quite ready to share, all our internal bureaucracy for code release is also done so there are no problems of that kind left.

 

Perhaps we can upload the code for you guys and any others interested to build and test out (perhaps help with some bugfixing of issues you find) before an official version is built and pushed to the maven repo? I don’t know how it’s normally done, I’m a first time commiter.

On that not I have another question: I’ve seen that the existing Gerrit- and the git-plugin is hosted on GitHub and then periodically pushed into the svn repo, since we like git that would be good (and cool) to do, but I’m not sure if it’s worth the effort. Does anyone have any suggestions on the approach on this?

 

Hope to release soon.

BR

Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 7 juni 2010 22:05

Subject: Re: We would like to contribute a new Gerrit-plugin!

 

Hey guys -

 

Just wanted to check and see what the status of your plugin is - we're really looking forward to it here, since it seems like it'll fit our concurrent build model for pre-tested commits better than the existing plugin. 

 

A.

On Thu, May 27, 2010 at 11:49 AM, Andrew Bayer <[hidden email]> wrote:

Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

 

A.

 

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:


Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html

Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

 

 


Reply | Threaded
Open this post in threaded view
|

RE: We would like to contribute a new Gerrit-plugin!

Sandell, Robert

Ok.

 

GitHub users:

                rsandell

                GLundh

 

Java.net users

                rsandell

                GLundh (I think Gustaf already has commit access)

 

The artifactId is “gerrit-trigger” and the short name is “Gerrit Trigger” to distinguish from the original plugin.

 

A Jira component would be usefull as well J

You can set me (rsandell) as Lead on both the git and the Jira component if that is needed.

 

Thanks in advance!

//Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 8 juni 2010 22:22
To: [hidden email]
Subject: Re: We would like to contribute a new Gerrit-plugin!

 

I think the choosing strategy is probably the best approach - I believe Jyrki did some work on the git plugin to make the choosing strategy extensible, so that you'd define your choosing strategy in your plugin, not in the git plugin, but I'm not sure what ended up happening with that.

 

And yes, GitHub is fine - just let us know the github usernames for any users you want to have push permission to the GitHub repo and we can get it set up under github.com/hudson. You'll also want to get java.net accounts and let us know those as well, so that you can have write access to the SVN repo and the Maven repo.

 

A.

On Tue, Jun 8, 2010 at 7:52 PM, Sandell, Robert <[hidden email]> wrote:

Hi,

 

The status is quite good, I have been doing some testing and finalization the last weeks, and through it works really well on my development machine with a local Gerrit and Hudson installation I haven’t been able to test it on a larger scale in a production like environment yet, so I don’t dare to say that it works until I have put it through some heavy load :)

 

Last week we hit a small bump in the road when we were trying to use it together with the git plugin, so far we have used it with freestyle shell scripts that fetches code, but since you guys really liked our approach I thought that I should make sure that it works well with the git plugin as well.

The problem is that I couldn’t get the GitSCM to fetch an explicit refspec, when the trigger schedules a build it puts an bunch of ParameterValues into a ParameterAction so that, among others, the REFSPEC value from Gerrit is available as an env var. The git plugin can resolve those values correctly if you specify $REFSPEC to the refspec config in the job but the git plugin doesn’t choose the correct id in the refspec to build no matter how I try to configure it.

I’ve solved the problem by implementing yet another “Choosing strategy” in the git plugin that builds FETCH_HEAD, but I’m not proud of that solution, it feels a bit “quick ´n dirty” and it also gives the user the option between “Default”, “Gerrit” and “Gerrit Trigger” which is probably a bit confusing. Does anyone have any better idea?

 

But besides the large scale testing and the git plugin issue we feel quite ready to share, all our internal bureaucracy for code release is also done so there are no problems of that kind left.

 

Perhaps we can upload the code for you guys and any others interested to build and test out (perhaps help with some bugfixing of issues you find) before an official version is built and pushed to the maven repo? I don’t know how it’s normally done, I’m a first time commiter.

On that not I have another question: I’ve seen that the existing Gerrit- and the git-plugin is hosted on GitHub and then periodically pushed into the svn repo, since we like git that would be good (and cool) to do, but I’m not sure if it’s worth the effort. Does anyone have any suggestions on the approach on this?

 

Hope to release soon.

BR

Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 7 juni 2010 22:05

Subject: Re: We would like to contribute a new Gerrit-plugin!

 

Hey guys -

 

Just wanted to check and see what the status of your plugin is - we're really looking forward to it here, since it seems like it'll fit our concurrent build model for pre-tested commits better than the existing plugin. 

 

A.

On Thu, May 27, 2010 at 11:49 AM, Andrew Bayer <[hidden email]> wrote:

Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

 

A.

 

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:


Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html

Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: We would like to contribute a new Gerrit-plugin!

Andrew Bayer
Done: http://github.com/hudson/gerrit-trigger-plugin 

A.

On Thu, Jun 10, 2010 at 4:54 AM, Sandell, Robert <[hidden email]> wrote:

Ok.

 

GitHub users:

                rsandell

                GLundh

 

Java.net users

                rsandell

                GLundh (I think Gustaf already has commit access)

 

The artifactId is “gerrit-trigger” and the short name is “Gerrit Trigger” to distinguish from the original plugin.

 

A Jira component would be usefull as well J

You can set me (rsandell) as Lead on both the git and the Jira component if that is needed.

 

Thanks in advance!

//Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 8 juni 2010 22:22


To: [hidden email]
Subject: Re: We would like to contribute a new Gerrit-plugin!

 

I think the choosing strategy is probably the best approach - I believe Jyrki did some work on the git plugin to make the choosing strategy extensible, so that you'd define your choosing strategy in your plugin, not in the git plugin, but I'm not sure what ended up happening with that.

 

And yes, GitHub is fine - just let us know the github usernames for any users you want to have push permission to the GitHub repo and we can get it set up under github.com/hudson. You'll also want to get java.net accounts and let us know those as well, so that you can have write access to the SVN repo and the Maven repo.

 

A.

On Tue, Jun 8, 2010 at 7:52 PM, Sandell, Robert <[hidden email]> wrote:

Hi,

 

The status is quite good, I have been doing some testing and finalization the last weeks, and through it works really well on my development machine with a local Gerrit and Hudson installation I haven’t been able to test it on a larger scale in a production like environment yet, so I don’t dare to say that it works until I have put it through some heavy load :)

 

Last week we hit a small bump in the road when we were trying to use it together with the git plugin, so far we have used it with freestyle shell scripts that fetches code, but since you guys really liked our approach I thought that I should make sure that it works well with the git plugin as well.

The problem is that I couldn’t get the GitSCM to fetch an explicit refspec, when the trigger schedules a build it puts an bunch of ParameterValues into a ParameterAction so that, among others, the REFSPEC value from Gerrit is available as an env var. The git plugin can resolve those values correctly if you specify $REFSPEC to the refspec config in the job but the git plugin doesn’t choose the correct id in the refspec to build no matter how I try to configure it.

I’ve solved the problem by implementing yet another “Choosing strategy” in the git plugin that builds FETCH_HEAD, but I’m not proud of that solution, it feels a bit “quick ´n dirty” and it also gives the user the option between “Default”, “Gerrit” and “Gerrit Trigger” which is probably a bit confusing. Does anyone have any better idea?

 

But besides the large scale testing and the git plugin issue we feel quite ready to share, all our internal bureaucracy for code release is also done so there are no problems of that kind left.

 

Perhaps we can upload the code for you guys and any others interested to build and test out (perhaps help with some bugfixing of issues you find) before an official version is built and pushed to the maven repo? I don’t know how it’s normally done, I’m a first time commiter.

On that not I have another question: I’ve seen that the existing Gerrit- and the git-plugin is hosted on GitHub and then periodically pushed into the svn repo, since we like git that would be good (and cool) to do, but I’m not sure if it’s worth the effort. Does anyone have any suggestions on the approach on this?

 

Hope to release soon.

BR

Bobby

 

From: Andrew Bayer [mailto:[hidden email]]
Sent: den 7 juni 2010 22:05

Subject: Re: We would like to contribute a new Gerrit-plugin!

 

Hey guys -

 

Just wanted to check and see what the status of your plugin is - we're really looking forward to it here, since it seems like it'll fit our concurrent build model for pre-tested commits better than the existing plugin. 

 

A.

On Thu, May 27, 2010 at 11:49 AM, Andrew Bayer <[hidden email]> wrote:

Yeah, that should be fine - for what it's worth, the existing plugin isn't hosted in the Hudson SVN repo. It's over at github (http://github.com/hudson/Hudson-Gerrit-Plugin). When you're setting up your plugin, the important thing is to make sure the artifactId in your POM is different from the existing plugin's artifactId, or there'll be conflicts. The current plugin uses "gerrit" for its artifactId.

 

A.

 

On Wed, May 26, 2010 at 7:54 AM, GLundh <[hidden email]> wrote:


Hi!

Thanks for your comments!

We are currently finalizing the code and preparing for the contribution. In
a week/few weeks we will contribute the plug-in as a separate project.
If/when the community deems the new plug-in fully covers the functionality
of the old one, we can merge/replace the current one. Is this OK?

Br
Gustaf & Bobby
--
View this message in context: http://hudson.361315.n4.nabble.com/We-would-like-to-contribute-a-new-Gerrit-plugin-tp2224606p2231795.html

Sent from the Hudson dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]