IRC plugin release?

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

IRC plugin release?

Kohsuke Kawaguchi-2

Hi,

It looks like IRC plugin is ready to release its first version.

Renaud, would you like to do that, or would you like me to do that?

BTW, I have a few RFEs:

- it would be nice if different jobs can choose different channels
   to report the result.

- I wonder if bot could be made smarter. For example, what happens here
   often is that:

   1. someone asks me to fix a bug in my project
   2. I put a fix, and I'd like him to be notified when the build is
      ready

   If I can tell bot upfront to notify someone else when a build with
   my change is done, that would be mighty handy.

   Similarly, if my change breaks a build, it would be really nice if the
   bot pings me so.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Renaud Bruyeron-2

Interesting, I did not think of these use-cases.
In light of what the competition is doing, it would be great if the
notification logic could be abstracted out of the plugin, and the plugin
just be an IRC implementation - what I am getting at is that being able
to implement a MSN or jabber version should be as simple as dropping in
a protocol library and implementing a couple of methods from a
AbstractIMPublisher.

To support the features below, the AbstractIMPublisher would need to
have the following capabilities:
* map Hudson people with IM nicknames - so that specific IM users can be
notified
* have hooks to wire in IM specific capabilities (such as
isChannelCapable(), which would return false for MSN but true for IRC or
jabber, and this would let us display a per-project channel selector)

I guess plugins cannot "do" things to each other at this point, so the
AbstractIMPublisher would need to be in the Hudson core, am I right?

 - Renaud

Kohsuke Kawaguchi wrote:

>
> Hi,
>
> It looks like IRC plugin is ready to release its first version.
>
> Renaud, would you like to do that, or would you like me to do that?
>
> BTW, I have a few RFEs:
>
> - it would be nice if different jobs can choose different channels
>   to report the result.
>
> - I wonder if bot could be made smarter. For example, what happens here
>   often is that:
>
>   1. someone asks me to fix a bug in my project
>   2. I put a fix, and I'd like him to be notified when the build is
>      ready
>
>   If I can tell bot upfront to notify someone else when a build with
>   my change is done, that would be mighty handy.
>
>   Similarly, if my change breaks a build, it would be really nice if the
>   bot pings me so.
>


--
Renaud Bruyeron <[hidden email]>
Software Architect, FullSIX France
Tel: +33(1)49 68 75 29

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

Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Renaud Bruyeron-2
In reply to this post by Kohsuke Kawaguchi-2



Kohsuke Kawaguchi wrote:
>
> It looks like IRC plugin is ready to release its first version.
>
> Renaud, would you like to do that, or would you like me to do that?
>
Is there a process to do this? (I am new to maven and to dev.java.net
;-)). I guess it is simply a matter
of pushing the hpi using the upload interface in Document & Files? The
plugins page should also be updated. Or is there more to it? (like
tagging CVS and changing <version/> in the pom.xml ?)
> BTW, I have a few RFEs:
>
Should we use the issue tracker for this? (btw, the issue tracker only
lists the "www" component)
> - it would be nice if different jobs can choose different channels
>   to report the result.
>
Good point

> - I wonder if bot could be made smarter. For example, what happens here
>   often is that:
>
>   1. someone asks me to fix a bug in my project
>   2. I put a fix, and I'd like him to be notified when the build is
>      ready
>
>   If I can tell bot upfront to notify someone else when a build with
>   my change is done, that would be mighty handy.
>
How do you see this work? Would that be something you do in the hudson
interface (through a "notify people after next successful build"
screen)? Or something smarter (harder ;-)) like a special token in the
SCM commit log message that Hudson picks up and uses to invoke the notifier?
>   Similarly, if my change breaks a build, it would be really nice if the
>   bot pings me so.
>
Yes, I need a Map<People,Nickname> to be able to do that. I'll take a
look. Ideally I would love a way for the plugin to extend the People
screens so that I can add the mappings there, but I don't know if this
exists yet.

 - Renaud

--
Renaud Bruyeron <[hidden email]>
Software Architect, FullSIX France
Tel: +33(1)49 68 75 29

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

Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Kohsuke Kawaguchi-2
In reply to this post by Renaud Bruyeron-2
Renaud Bruyeron wrote:
> Interesting, I did not think of these use-cases.
> In light of what the competition is doing, it would be great if the
> notification logic could be abstracted out of the plugin, and the plugin
> just be an IRC implementation - what I am getting at is that being able
> to implement a MSN or jabber version should be as simple as dropping in
> a protocol library and implementing a couple of methods from a
> AbstractIMPublisher.

+1 for extensibility like this.

I wonder if there should be just one IM plugin + its own extension point
for protocol implementations. When you present it to users, if you have
one plugin for each protocol, you end up getting a whole list of IM
protocols, like this:

   [x] Notify the build results to IRC
       ...
   [ ] Notify the build results to MSN
       ...
   [ ] Notify the build results to Jabber
       ...

Making this one plugin would avoid this problem, since there will be
just one checkbox.


> To support the features below, the AbstractIMPublisher would need to
> have the following capabilities:
> * map Hudson people with IM nicknames - so that specific IM users can be
> notified

This you can do with UserProperty. See Mailer.UserProperty for how it
stores e-mail address for each user and makes it configurable.

> * have hooks to wire in IM specific capabilities (such as
> isChannelCapable(), which would return false for MSN but true for IRC or
> jabber, and this would let us display a per-project channel selector)
>
> I guess plugins cannot "do" things to each other at this point, so the
> AbstractIMPublisher would need to be in the Hudson core, am I right?

It is relatively easy to extend Hudson to allow inter-dependencies
between plugins, and it's needed anyway --- I have more than one plugins
that use http://javanetasks.dev.java.net/ library and I don't need two
copies.

So the idea is that you first write a jar module that hosts
"AbstractIMPublisher" and related classes, then write one plugin to
package that to .hpi, then have other plugins depend on that library/hpi.

An .hpi file is really just a war file, and I don't think Maven lets one
declare a dependency to a war file to pick up its classes, so the exact
mechanism in which we declare the dependency needs to be worked out, but
what I outlined above should work.

That said, the IM support seems to be a fairly ubiquitous feature, so I
think it makes sense to have generic IM support in the core, then have
protocol implementations as plugins. Why don't we start with this
approach? We can switch later if it makes sense.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Renaud Bruyeron-2
Kohsuke Kawaguchi wrote:
> Renaud Bruyeron wrote:
>> To support the features below, the AbstractIMPublisher would need to
>> have the following capabilities:
>> * map Hudson people with IM nicknames - so that specific IM users can
>> be notified
>
> This you can do with UserProperty. See Mailer.UserProperty for how it
> stores e-mail address for each user and makes it configurable.
>
I found out after sending my email when I looked at the source ;-)
Indeed, this is most excellent and will do exactly what I need.

>> * have hooks to wire in IM specific capabilities (such as
>> isChannelCapable(), which would return false for MSN but true for IRC
>> or jabber, and this would let us display a per-project channel selector)
>>
>> I guess plugins cannot "do" things to each other at this point, so
>> the AbstractIMPublisher would need to be in the Hudson core, am I right?
>
> It is relatively easy to extend Hudson to allow inter-dependencies
> between plugins, and it's needed anyway --- I have more than one
> plugins that use http://javanetasks.dev.java.net/ library and I don't
> need two copies.
>
> So the idea is that you first write a jar module that hosts
> "AbstractIMPublisher" and related classes, then write one plugin to
> package that to .hpi, then have other plugins depend on that library/hpi.
>
> An .hpi file is really just a war file, and I don't think Maven lets
> one declare a dependency to a war file to pick up its classes, so the
> exact mechanism in which we declare the dependency needs to be worked
> out, but what I outlined above should work.
>
I am not sure I am following you - how do you express the dependency? My
understanding of "dependency" between 2 plugins is that plugin A exports
a service or an interface, and Hudson makes that available in plugin B's
classloader. Right? I must admit I am not "au fait" regarding the
classloader machinery in Hudson, but my assumption here is that plugins
are loaded via isolated classloaders that share the webapp classloader
as a common parent. Am I correct?

I guess what would be great is something like OSGi :-)

 - Renaud

--
Renaud Bruyeron <[hidden email]>
Software Architect, FullSIX France
Tel: +33(1)49 68 75 29

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

Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Kohsuke Kawaguchi-2
In reply to this post by Renaud Bruyeron-2
Renaud Bruyeron wrote:

>
>
> Kohsuke Kawaguchi wrote:
>>
>> It looks like IRC plugin is ready to release its first version.
>>
>> Renaud, would you like to do that, or would you like me to do that?
>>
> Is there a process to do this? (I am new to maven and to dev.java.net
> ;-)). I guess it is simply a matter
> of pushing the hpi using the upload interface in Document & Files? The
> plugins page should also be updated. Or is there more to it? (like
> tagging CVS and changing <version/> in the pom.xml ?)
I have an automation script to do this, but basically it amounts to
running "mvn release:prepare && mvn:release:perform" then post the file
to docs&files section.


>> BTW, I have a few RFEs:
>>
> Should we use the issue tracker for this? (btw, the issue tracker only
> lists the "www" component)

Ah, yes.


>> - I wonder if bot could be made smarter. For example, what happens here
>>   often is that:
>>
>>   1. someone asks me to fix a bug in my project
>>   2. I put a fix, and I'd like him to be notified when the build is
>>      ready
>>
>>   If I can tell bot upfront to notify someone else when a build with
>>   my change is done, that would be mighty handy.
>>
> How do you see this work? Would that be something you do in the hudson
> interface (through a "notify people after next successful build"
> screen)? Or something smarter (harder ;-)) like a special token in the
> SCM commit log message that Hudson picks up and uses to invoke the notifier?
No, I was thinking about talking to the IRC bot. It knows me, so it
should understand who I am. This kind of "notify him when it's done"
doesn't happen too often, so I think it's easier if such is done by
talking to the bot, instead of going to the web interface.


>>   Similarly, if my change breaks a build, it would be really nice if the
>>   bot pings me so.
>>
> Yes, I need a Map<People,Nickname> to be able to do that. I'll take a
> look. Ideally I would love a way for the plugin to extend the People
> screens so that I can add the mappings there, but I don't know if this
> exists yet.
>
>  - Renaud
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Renaud Bruyeron-2
Kohsuke Kawaguchi wrote:

>>>   If I can tell bot upfront to notify someone else when a build with
>>>   my change is done, that would be mighty handy.
>>>
>> How do you see this work? Would that be something you do in the
>> hudson interface (through a "notify people after next successful
>> build" screen)? Or something smarter (harder ;-)) like a special
>> token in the SCM commit log message that Hudson picks up and uses to
>> invoke the notifier?
>
> No, I was thinking about talking to the IRC bot. It knows me, so it
> should understand who I am. This kind of "notify him when it's done"
> doesn't happen too often, so I think it's easier if such is done by
> talking to the bot, instead of going to the web interface.
Currently the bot supports this:
!hudson build myproject
This queues up the project "myproject" for build, unless it's already in
the queue.
Are you suggesting something like this:
!hudson build(kohsuke) myproject
This would notify the person "kohsuke" with the status of the build and
a url. However if the build fails then what do we do? I guess we could
report back to the person initiating the build that the build failed.

Is this what you had in mind?

 - Renaud

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

Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Kohsuke Kawaguchi-2
In reply to this post by Renaud Bruyeron-2
Renaud Bruyeron wrote:
>> An .hpi file is really just a war file, and I don't think Maven lets
>> one declare a dependency to a war file to pick up its classes, so the
>> exact mechanism in which we declare the dependency needs to be worked
>> out, but what I outlined above should work.
>>
> I am not sure I am following you - how do you express the dependency? My
> understanding of "dependency" between 2 plugins is that plugin A exports
> a service or an interface, and Hudson makes that available in plugin B's
> classloader. Right?

Yes. It's bit tricky, but it's been done, and it can be done one more time.

 > I must admit I am not "au fait" regarding the
> classloader machinery in Hudson, but my assumption here is that plugins
> are loaded via isolated classloaders that share the webapp classloader
> as a common parent. Am I correct?

Yes.

> I guess what would be great is something like OSGi :-)

Indeed. Or some kind of container. The tricky part as always is the
compatibility.

This should teach me something about rolling my own...


But anyway, let's go with putting AbstractIMPublisher in the core, while
I work on the improvements to plugin classloaders. Why don't you design
that in the ircbot plugin, and when it looks good, we'll move that over
to the core.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IRC plugin release?

Kohsuke Kawaguchi-2
In reply to this post by Renaud Bruyeron-2
Renaud Bruyeron wrote:
> Currently the bot supports this:
> !hudson build myproject
> This queues up the project "myproject" for build, unless it's already in
> the queue.

Cool. I wonder if it's possible to make it "understand" English. So that
it will go something like:

   kohsuke: Hi, can you build jaxb-ri for me?
   hudson: Got it. Scheduled jaxb-ri #1632
      ... later ...
   hudson: Hey, jaxb-ri #1632 is done.

My (limited) experience with the "zakim" IRC bot [1] says a rather dumb
algorithm would do a fair good job. For example, in the above case, you
could just tokenize my sentence, remove common English words like "for",
"can", etc, then pick up "build" (as the instruction for building a new
project) and "jaxb-ri", which matches one of the projects Hudson knows.

I think this would be much easier to use, and it's more fun to work on!

> Are you suggesting something like this:
> !hudson build(kohsuke) myproject
> This would notify the person "kohsuke" with the status of the build and
> a url. However if the build fails then what do we do? I guess we could
> report back to the person initiating the build that the build failed.
>
> Is this what you had in mind?
>
>  - Renaud
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
[1] http://www.w3.org/2001/12/zakim-irc-bot.html
--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment