Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAllow hubot to react on events #344
Conversation
This comment has been minimized.
This comment has been minimized.
This looks interesting, but I'd like to see some docs and some usage examples before this gets merged. |
This comment has been minimized.
This comment has been minimized.
Good point, i'll add docs. Any wishes where to add? And examples? in code or would you like to see them in docs. b/c at the included script there are IMO no real usecase for that. |
This comment has been minimized.
This comment has been minimized.
README is the logical place. Doesn't look like there's any API changes, but maybe it'd be worthwhile to add some convenience methods to have a point to be documenting. I wouldn't force them into the included scripts if it doesn't apply. But, maybe a new simple script that it would be useful for? On Aug 28, 2012, at 8:54 AM, Ole Michaelis wrote:
|
This comment has been minimized.
This comment has been minimized.
This is only README.md next is to find a suitable solution for an example, beside that mentioned in README or might this be already enough? |
This comment has been minimized.
This comment has been minimized.
+1 |
This comment has been minimized.
This comment has been minimized.
This would be better if you just extended the class Robot extends EventEmitter Then you can have: robot.on 'something', ->
# ... Rather than an ugly |
This comment has been minimized.
This comment has been minimized.
Extending would break all kind of code semantics. If you prefere the |
This comment has been minimized.
This comment has been minimized.
I agree with @NesQuick. The |
This comment has been minimized.
This comment has been minimized.
The |
This comment has been minimized.
This comment has been minimized.
So the best example why not use inheritance is that if we some day need another functionality which can be archived by inheritance, there is no multiple inheritance. |
This comment has been minimized.
This comment has been minimized.
Closing this, it can lead to a lot of weird issues with different scripts listening for different events which may not be compatible with each other. |
tombell
closed this
Jan 10, 2013
This comment has been minimized.
This comment has been minimized.
I'm thinking this could be a nice feature for v3.0. You say it could weird issues with different scripts listening for different events, but hubot has that problem with different scripts listening for different text. The best way to solve that is with documentation, I think. Scripts that emit events should document that, like we do dependencies, configs, etc. Same for scripts that consume the events. The use case I have in mind is for making scripts that consume some service, and allow extension by sending these events. For example, I have a private script that checks a PagerDuty schedule, and texts as a person as they come on call, and also notifies a Campfire room. Because of that, I can't really open source it... but if I have it emit something like pagerduty.shiftchange, I could open source that script, and as cript to consume the event and post to Campfire, then have a private script for the text notification. |
technicalpickles
reopened this
Jan 13, 2013
This comment has been minimized.
This comment has been minimized.
This can easily just be added to hubot with a script, I don't think complicating hubot more is a good direction. {EventEmitter} = require 'events'
module.exports = (robot) ->
robot.events or= new EventEmitter
# do shit |
This comment has been minimized.
This comment has been minimized.
That code snippet, particularly of setting But thinking about it, if you are in a pagerduty script, and you set |
This comment has been minimized.
This comment has been minimized.
My code snippet functions exactly like the code that would be added to hubot itself, if every script wanting to use events included that at the top it would work fine. The |
This comment has been minimized.
This comment has been minimized.
I was in the process of improving this PR. I would love to see it in v3.0 please give me some more weeks to improve it. I also really like the way @technicalpickles described, this was also my initial attempt to this PR. So I think we're on the same way having such a feature. Is there a milestone or roadmap for 3.0? I would love to help also with other tickets. |
Feb 8, 2013
and others
added some commits
This comment has been minimized.
This comment has been minimized.
Oh shit - long time ago since i did the last pull/merge/rebase. But I finally managed to complete this. I hope the semantics now matches the expectations and documentation and examples are verbose enough |
tombell
reviewed
Feb 12, 2013
# [arg1] - Event argument one (optional). | ||
# [arg2] - Event argument two (optional). | ||
# [....] - Event argument n (optional). | ||
# |
This comment has been minimized.
This comment has been minimized.
tombell
Feb 12, 2013
Contributor
This should just be args - An Array of arguments emitted by the event
.
This comment has been minimized.
This comment has been minimized.
OleMchls
Feb 12, 2013
Author
Contributor
But that's not an array, it's a bunch of arguments. First argument is always treated as the event name, so if you would pass an array, the event name would be the string representation of that array which isn't complaint to the event emitter interface.
This comment has been minimized.
This comment has been minimized.
tombell
Feb 14, 2013
Contributor
What is the reason for using (args...)
instead of (event, args...)
which is more understandable?
This comment has been minimized.
This comment has been minimized.
OleMchls
Feb 14, 2013
Author
Contributor
fixed :) also applied the changes to the on method to make it more consistent
pushed a commit
that referenced
this pull request
Feb 16, 2013
tombell
merged commit 41741ca
into
hubotio:master
Feb 16, 2013
This comment has been minimized.
This comment has been minimized.
rdohms
commented
Feb 22, 2013
I'm getting an error which seems to track back to this PR:
Am I missing a library or something? |
This comment has been minimized.
This comment has been minimized.
a release of hubot containing this PR hasn't been released. |
This comment has been minimized.
This comment has been minimized.
@rdohms can you provide more details pls? I cant reproduce it |
This comment has been minimized.
This comment has been minimized.
rdohms
commented
Feb 22, 2013
@NesQuick its just a regular checkout of hubot with the regular stuff on the unix how-to. I checked out version 2.4.6 and no more problems. |
This comment has been minimized.
This comment has been minimized.
Oh yeah, took a while until I get the problem, sorry. I think it's ok until we'll make a release |
OleMchls commentedAug 28, 2012
Events might get triggered by scripts.
For example: You have a script, which can trigger and event that some one committed to a repo. This script can be used by anyone, but the reaction should be different by every company. So it's possible to trigger a build, or just post a message in chat.
As a plus with the same event triggered by different scripts, so it wouldn't make a difference if you commit into github or just another (maybe SVN) repo. But other scripts can rely on that 'commit-received' command and act the same way.