hubot 5.0.5 → 5.0.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +6 -5
- package/.editorconfig +0 -14
- package/.github/stale.yml +0 -23
- package/.github/workflows/nodejs-macos.yml +0 -26
- package/.github/workflows/nodejs-ubuntu.yml +0 -28
- package/.github/workflows/nodejs-windows.yml +0 -26
- package/.github/workflows/release.yml +0 -37
- package/bin/e2e-test.sh +0 -47
- package/docs/adapters/campfire.md +0 -79
- package/docs/adapters/development.md +0 -125
- package/docs/adapters/shell.md +0 -24
- package/docs/adapters.md +0 -27
- package/docs/deploying/azure.md +0 -97
- package/docs/deploying/bluemix.md +0 -111
- package/docs/deploying/heroku.md +0 -66
- package/docs/deploying/unix.md +0 -72
- package/docs/deploying/windows.md +0 -66
- package/docs/deploying.md +0 -11
- package/docs/implementation.md +0 -55
- package/docs/index.md +0 -125
- package/docs/patterns.md +0 -265
- package/docs/scripting.md +0 -1051
- package/examples/hubot-start.ps1 +0 -12
- package/examples/hubot.service +0 -27
- package/script/bootstrap +0 -3
- package/script/release +0 -44
- package/script/server +0 -3
- package/script/smoke-test +0 -3
- package/script/test +0 -3
- package/test/adapter_test.js +0 -97
- package/test/brain_test.js +0 -336
- package/test/datastore_test.js +0 -154
- package/test/es2015_test.js +0 -199
- package/test/fixtures/MockAdapter.coffee +0 -10
- package/test/fixtures/MockAdapter.mjs +0 -43
- package/test/fixtures/TestScript.coffee +0 -9
- package/test/fixtures/TestScript.js +0 -13
- package/test/fixtures/mock-adapter.js +0 -35
- package/test/listener_test.js +0 -379
- package/test/message_test.js +0 -46
- package/test/middleware_test.js +0 -507
- package/test/robot_test.js +0 -1153
- package/test/shell_test.js +0 -73
- package/test/user_test.js +0 -29
|
@@ -1,111 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
permalink: /docs/deploying/bluemix/
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Deploying to Bluemix
|
|
6
|
-
|
|
7
|
-
If you've been following along with [Getting Started](../index.md), it's time
|
|
8
|
-
to deploy so you can use it beyond just your local machine.
|
|
9
|
-
[IBM Bluemix](http://bluemix.net) is a way to deploy hubot as an alternative to
|
|
10
|
-
[Heroku](heroku.md). It is built on the open-source project
|
|
11
|
-
[Cloud Foundry](https://www.cloudfoundry.org/), so we'll be using the `cf cli`
|
|
12
|
-
throughout these examples.
|
|
13
|
-
|
|
14
|
-
Hubot was originally very closely coupled to Heroku, so there are a couple of
|
|
15
|
-
things to clean up first that we don't need or that might get in the way on
|
|
16
|
-
another platform:
|
|
17
|
-
* remove `Procfile` as we'll create the `manifest.yml` that Bluemix needs in a
|
|
18
|
-
moment
|
|
19
|
-
* remove the `hubot-heroku-keepalive` line from `external_scripts.json` and also
|
|
20
|
-
remove the related npm module (it causes errors on other platforms):
|
|
21
|
-
|
|
22
|
-
npm uninstall --save hubot-heroku-keepalive
|
|
23
|
-
|
|
24
|
-
In preparation for working with Bluemix, install the [Cloud Foundry
|
|
25
|
-
CLI](https://github.com/cloudfoundry/cli/releases), and create a [Bluemix
|
|
26
|
-
Account](http://bluemix.net).
|
|
27
|
-
|
|
28
|
-
First we need to define a `manifest.yml` file in the root directory. The
|
|
29
|
-
contents of the manifest at the bare minimum should look like:
|
|
30
|
-
|
|
31
|
-
```yml
|
|
32
|
-
applications:
|
|
33
|
-
- name: myVeryOwnHubot
|
|
34
|
-
command: ./bin/hubot --adapter slack
|
|
35
|
-
instances: 1
|
|
36
|
-
memory: 512M
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
In this example, we're using the slack adapter, if you choose slack as your
|
|
40
|
-
adapter when creating a hubot this will work, otherwise add the `hubot-slack`
|
|
41
|
-
module to your `package.json`. **Change the name of your hubot in the
|
|
42
|
-
`manifest.yml` file** because otherwise your application will clash with someone
|
|
43
|
-
else's who already deployed an app called this! There are many more useful
|
|
44
|
-
things you can change about your hubot using the manifest file, so check out
|
|
45
|
-
[these docs](https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html)
|
|
46
|
-
for more information.
|
|
47
|
-
|
|
48
|
-
You then need to connect your hubot project to Bluemix:
|
|
49
|
-
|
|
50
|
-
```sh
|
|
51
|
-
$ cd your_hubot_project
|
|
52
|
-
$ cf api https://api.ng.bluemix.net
|
|
53
|
-
$ cf login
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
Note that the `cf api` command changes per Bluemix region so to deploy somewhere
|
|
57
|
-
other than "US South", replace this api as appropriate. The `cf login` command
|
|
58
|
-
will prompt you with your login credentials.
|
|
59
|
-
|
|
60
|
-
Next, we need to set up our environment variables, but we need to create the app
|
|
61
|
-
first. It won't work properly without the environment variables it needs, so
|
|
62
|
-
we'll first of all use the `--no-start` flag to deploy but not attempt to start
|
|
63
|
-
it.
|
|
64
|
-
|
|
65
|
-
```sh
|
|
66
|
-
$ cf push NAME_OF_YOUR_HUBOT_APP --no-start
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
Now the app exists, we can set its environment variables. To access slack,
|
|
70
|
-
you'll need a slack token from the "Apps and Integrations" page; it's visible
|
|
71
|
-
when you go to create a slackbot. Copy that token and set it as an environment
|
|
72
|
-
variable called `HUBOT_SLACK_TOKEN`, like this:
|
|
73
|
-
|
|
74
|
-
```sh
|
|
75
|
-
$ cf set-env NAME_OF_YOUR_HUBOT_APP HUBOT_SLACK_TOKEN TOKEN_VALUE
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
If you have other environment variables to set, such as configuring the
|
|
79
|
-
`REDIS_URL` for `hubot-redis-brain`, this is a good time to do that.
|
|
80
|
-
|
|
81
|
-
Finally, we're ready to go! Deploy "for real" this time:
|
|
82
|
-
|
|
83
|
-
```sh
|
|
84
|
-
$ cf push NAME_OF_YOUR_HUBOT_APP
|
|
85
|
-
```
|
|
86
|
-
|
|
87
|
-
You should see your bot connect to slack!
|
|
88
|
-
|
|
89
|
-
### Further Reading
|
|
90
|
-
|
|
91
|
-
- [Deploying Cloud Foundry Apps To Bluemix](https://www.ng.bluemix.net/docs/cfapps/runtimes.html)
|
|
92
|
-
- [Neploying Node.js Apps to Bluemix](https://www.ng.bluemix.net/docs/starters/nodejs/index.html)
|
|
93
|
-
- [Setting up your manifest](https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html)
|
|
94
|
-
- [Understanding the CF CLI](https://www.ng.bluemix.net/docs/cli/reference/cfcommands/index.html)
|
|
95
|
-
- [Setting up a Build Pipleline in Bluemix](https://www.ng.bluemix.net/docs/#services/DeliveryPipeline/index.html#getstartwithCD)
|
|
96
|
-
|
|
97
|
-
### Troubleshooting
|
|
98
|
-
|
|
99
|
-
**Bot doesn't connect**
|
|
100
|
-
|
|
101
|
-
Check your logs for more information using the command `cf logs YOUR_APP_NAME
|
|
102
|
-
--recent`. If you have NodeJS installed locally, you can also try running the
|
|
103
|
-
bot on your local machine to inspect any output: simply do `bin/hubot` from the
|
|
104
|
-
top level of the project.
|
|
105
|
-
|
|
106
|
-
**Bot crashes repeatedly**
|
|
107
|
-
|
|
108
|
-
It is sometimes necessary to to assign more memory to your hubot, depending
|
|
109
|
-
which plugins you are using (if your app crashes with error 137, try increasing
|
|
110
|
-
the memory limit).
|
|
111
|
-
|
package/docs/deploying/heroku.md
DELETED
|
@@ -1,66 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
permalink: /docs/deploying/heroku/
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Deploying to Heroku
|
|
6
|
-
|
|
7
|
-
If you've been following along with [Getting Started](../index.md), it's time to deploy so you can use it beyond just your local machine.
|
|
8
|
-
[Heroku](http://www.heroku.com/) is an easy and supported way to deploy hubot.
|
|
9
|
-
|
|
10
|
-
Install the [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) to start, then follow their '[Getting Started](https://devcenter.heroku.com/articles/heroku-cli#getting-started)' instructions, including logging in the first time:
|
|
11
|
-
|
|
12
|
-
% heroku login
|
|
13
|
-
Enter your Heroku credentials.
|
|
14
|
-
Email: youremail@example.com
|
|
15
|
-
Password:
|
|
16
|
-
Could not find an existing public key.
|
|
17
|
-
Would you like to generate one? [Yn]
|
|
18
|
-
Generating new SSH public key.
|
|
19
|
-
Uploading ssh public key /Users/you/.ssh/id_rsa.pub
|
|
20
|
-
|
|
21
|
-
Inside your new hubot directory, make sure you've created a git repository, and that your work is committed:
|
|
22
|
-
|
|
23
|
-
% git init
|
|
24
|
-
% git add .
|
|
25
|
-
% git commit -m "Initial commit"
|
|
26
|
-
|
|
27
|
-
Then create a Heroku application:
|
|
28
|
-
|
|
29
|
-
% heroku create
|
|
30
|
-
Creating rosemary-britches-123... done, stack is cedar
|
|
31
|
-
http://rosemary-britches-123.herokuapp.com/ | git@heroku.com:rosemary-britches-123.git
|
|
32
|
-
Git remote heroku added
|
|
33
|
-
|
|
34
|
-
Before you deploy the application, you'll need to configure some environment
|
|
35
|
-
variables for hubot to use. The specific variables you'll need depends on which
|
|
36
|
-
[adapter](../adapters.md) and scripts you are using. For Campfire, with no other
|
|
37
|
-
scripts, you'd need to set the following environment variables:
|
|
38
|
-
|
|
39
|
-
% heroku config:set HUBOT_CAMPFIRE_ACCOUNT=yourcampfireaccount
|
|
40
|
-
% heroku config:set HUBOT_CAMPFIRE_TOKEN=yourcampfiretoken
|
|
41
|
-
% heroku config:set HUBOT_CAMPFIRE_ROOMS=comma,separated,list,of,rooms,to,join
|
|
42
|
-
|
|
43
|
-
At this point, you are ready to deploy and start chatting. With Heroku, that's a
|
|
44
|
-
git push away:
|
|
45
|
-
|
|
46
|
-
% git push heroku main
|
|
47
|
-
|
|
48
|
-
You'll see some text flying, and eventually some success. You should be able to
|
|
49
|
-
see your bot in your configured chat rooms at this point. If not, you can peek
|
|
50
|
-
at the logs to try to debug:
|
|
51
|
-
|
|
52
|
-
% heroku logs
|
|
53
|
-
|
|
54
|
-
If you make any changes to your hubot, just commit and push them as
|
|
55
|
-
before:
|
|
56
|
-
|
|
57
|
-
% git commit -am "Awesome scripts OMG"
|
|
58
|
-
% git push heroku main
|
|
59
|
-
|
|
60
|
-
Some scripts needs Redis to work, Heroku offers an addon called [Redis Cloud](https://addons.heroku.com/rediscloud), which has a free plan. To use it:
|
|
61
|
-
|
|
62
|
-
% heroku addons:create rediscloud
|
|
63
|
-
|
|
64
|
-
Note: the free redis plans don't offer any persistence so your hubot will lose all the information when it goes to sleep.
|
|
65
|
-
|
|
66
|
-
Free dynos on Heroku will [sleep after 30 minutes of inactivity](https://devcenter.heroku.com/articles/dyno-sleeping). That means your hubot would leave the chat room and only rejoin when it does get traffic. This is extremely inconvenient since most interaction is done through chat, and hubot has to be online and in the room to respond to messages. To get around this, you can use the [hubot-heroku-keepalive](https://github.com/hubot-scripts/hubot-heroku-keepalive) script, which will keep your free dyno alive for up to 18 hours/day. If you never want Hubot to sleep, you will need to [upgrade to Heroku's hobby plan](https://www.heroku.com/pricing).
|
package/docs/deploying/unix.md
DELETED
|
@@ -1,72 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
permalink: /docs/deploying/unix/
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Deploying to Unix
|
|
6
|
-
|
|
7
|
-
Because there are so many variations of Linux, and more generally UNIX, it's
|
|
8
|
-
difficult for the hubot team to have canonical documentation for installing and
|
|
9
|
-
deploying it to every version out there. So, this is an attempt to give an
|
|
10
|
-
overview of what's needed to get deploying.
|
|
11
|
-
|
|
12
|
-
There are 3 primary things to deploying and running hubot:
|
|
13
|
-
|
|
14
|
-
* node and npm
|
|
15
|
-
* a way to get source code updated on the server
|
|
16
|
-
* a way to start hubot, start it up if it crashes, and restart it when code
|
|
17
|
-
updates
|
|
18
|
-
|
|
19
|
-
## node and npm
|
|
20
|
-
|
|
21
|
-
To start, your UNIX server will need node and npm. Check out the node.js wiki
|
|
22
|
-
for [installing Node.js via package manager](https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager), [Building on GNU/Linux and other UNIX](https://github.com/joyent/node/wiki/Installation#building-on-gnulinux-and-other-unix).
|
|
23
|
-
|
|
24
|
-
## Updating code on the server
|
|
25
|
-
|
|
26
|
-
The simplest way to update your hubot's code is going to be to have a git
|
|
27
|
-
checkout of your hubot's source code (that you've created during [Getting Started](../index.md), not the [github/hubot repository](http://github.com/github/hubot), and just git pull to get change. This may
|
|
28
|
-
feel a dirty hack, but it works when you are starting out.
|
|
29
|
-
|
|
30
|
-
If you have a Ruby background, you might be more comfortable using
|
|
31
|
-
[capistrano](https://github.com/capistrano/capistrano).
|
|
32
|
-
|
|
33
|
-
If you have a [Chef](http://www.chef.io/chef/) background, there's a
|
|
34
|
-
[deploy](https://docs.chef.io/resource_deploy.html) resource for managing
|
|
35
|
-
deployments.
|
|
36
|
-
|
|
37
|
-
## Starting, stopping, and restarting hubot
|
|
38
|
-
|
|
39
|
-
Every hubot install has a `bin/hubot` script to handle starting up the hubot.
|
|
40
|
-
You can run this command from your git checkout on the server, but there are some problems you can encounter:
|
|
41
|
-
|
|
42
|
-
* you disconnect, and hubot dies
|
|
43
|
-
* hubot dies, for any reason, and doesn't start again
|
|
44
|
-
* it doesn't start up at boot automatically
|
|
45
|
-
|
|
46
|
-
For handling you disconnecting, you can start with running `bin/hubot` in
|
|
47
|
-
[screen session](http://www.gnu.org/software/screen/) or with
|
|
48
|
-
[nohup](http://linux.die.net/man/1/nohup).
|
|
49
|
-
|
|
50
|
-
For handling hubot dying, and restarting it automatically, you can imagine
|
|
51
|
-
running `bin/hubot` in a
|
|
52
|
-
[bash while loop](http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-7.html#ss7.3). But
|
|
53
|
-
really, you probably want some process monitoring using tools like
|
|
54
|
-
[monit](http://mmonit.com/monit/),
|
|
55
|
-
[god](http://godrb.com/),
|
|
56
|
-
[bluepill](https://github.com/arya/bluepill),
|
|
57
|
-
[upstart](http://upstart.ubuntu.com/),
|
|
58
|
-
[runit](http://smarden.org/runit/),
|
|
59
|
-
[systemd](http://freedesktop.org/wiki/Software/systemd/).
|
|
60
|
-
|
|
61
|
-
For starting at boot, you can create an init script appropriate for your UNIX
|
|
62
|
-
distribution. If you are using one of the process monitoring tools above, make
|
|
63
|
-
sure it boots at startup. See the [examples](https://github.com/github/hubot/tree/main/examples)
|
|
64
|
-
for configuration examples.
|
|
65
|
-
|
|
66
|
-
## Recommendations
|
|
67
|
-
|
|
68
|
-
This document has been deliberately light on strong recommendations. At a high
|
|
69
|
-
level though, it's strongly recommended to avoid anything that is overly manual
|
|
70
|
-
and non-repeatable. That would mean using your OS's packages and tools whenever
|
|
71
|
-
possible, and having a proper deploy tool to update hubot, and process
|
|
72
|
-
management to keep hubot running.
|
|
@@ -1,66 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
permalink: /docs/deploying/windows/
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
# Deploying to Windows
|
|
6
|
-
|
|
7
|
-
Hasn't been fully tested - YMMV
|
|
8
|
-
|
|
9
|
-
There are 4 primary steps to deploying and running hubot on a Windows machine:
|
|
10
|
-
|
|
11
|
-
* node and npm
|
|
12
|
-
* a way to get source code updated on the server
|
|
13
|
-
* setting up environment variables for hubot
|
|
14
|
-
* a way to start hubot, start it up if it crashes, and restart it when code updates
|
|
15
|
-
|
|
16
|
-
## node and npm
|
|
17
|
-
|
|
18
|
-
To start, your windows server will need node and npm.
|
|
19
|
-
The best way to do this is with [chocolatey](http://chocolatey.org) using the [nodejs.install](http://chocolatey.org/packages/nodejs.install) package.
|
|
20
|
-
I've found that sometimes the system path variable is not correctly set; ensure you can run node/npm from the command line. If needed set the PATH variable with `set PATH=%PATH%;\"C:\Program Files\nodejs\"`
|
|
21
|
-
|
|
22
|
-
Your other option is to install directly from [NodeJS](https://nodejs.org/) and run the current download (v0.12.4 as of this documentation). This should set your PATH variables for you.
|
|
23
|
-
|
|
24
|
-
## Updating code on the server
|
|
25
|
-
|
|
26
|
-
To get the code on your server, you can follow the instructions at [Getting Started](../index.md) on your local development machine or directly on the server. If you are building locally, push your hubot to GitHub and clone the repo onto your server. Don't clone the normal [github/hubot repository](http://github.com/github/hubot), make sure you're using the Yo Generator to build your own hubot.
|
|
27
|
-
|
|
28
|
-
## Setting up environment vars
|
|
29
|
-
|
|
30
|
-
You will want to set up your hubot environment variables on the server where it will run. You can do this by opening an administrative PowerShell and typing the following:
|
|
31
|
-
|
|
32
|
-
[Environment]::SetEnvironmentVariable("HUBOT_ADAPTER", "Campfire", "Machine")
|
|
33
|
-
|
|
34
|
-
This is equivalent to going into the system menu -> selecting advanced system settings -> environment vars and adding a new system variable called HUBOT_ADAPTER with the value of Campfire.
|
|
35
|
-
|
|
36
|
-
## Starting, stopping, and restarting hubot
|
|
37
|
-
|
|
38
|
-
Every hubot install has a `bin/hubot` script to handle starting up the hubot.
|
|
39
|
-
You can run this command directly from your hubot folder by typing the following:
|
|
40
|
-
|
|
41
|
-
.\bin\hubot –adapter campfire
|
|
42
|
-
|
|
43
|
-
There are a few issues if you call it manually, though.
|
|
44
|
-
|
|
45
|
-
* you disconnect, and hubot dies
|
|
46
|
-
* hubot dies, for any reason, and doesn't start again
|
|
47
|
-
* it doesn't start up at boot automatically
|
|
48
|
-
|
|
49
|
-
To fix this, you will want to create a .ps1 file with whatever name makes you happy that you will call from your hubot directory. There is a copy of this file in the `examples` directory [here](../../examples/hubot-start.ps1). It should contain the following:
|
|
50
|
-
|
|
51
|
-
Write-Host "Starting Hubot Watcher"
|
|
52
|
-
While (1)
|
|
53
|
-
{
|
|
54
|
-
Write-Host "Starting Hubot"
|
|
55
|
-
Start-Process powershell -ArgumentList ".\bin\hubot –adapter slack" -wait
|
|
56
|
-
}
|
|
57
|
-
|
|
58
|
-
Remember to allow local unsigned PowerShell scripts if you are using the .ps1 file to run hubot. Run this command in an Administrator PowerShell window.
|
|
59
|
-
|
|
60
|
-
Set-ExecutionPolicy RemoteSigned
|
|
61
|
-
|
|
62
|
-
You can set this .ps1 as scheduled task on boot if you like or some other way to start your process.
|
|
63
|
-
|
|
64
|
-
## Expanding the documentation
|
|
65
|
-
|
|
66
|
-
Not yet fleshed out. [Help contribute by submitting a pull request, please?](https://github.com/github/hubot/pull/new/main)
|
package/docs/deploying.md
DELETED
package/docs/implementation.md
DELETED
|
@@ -1,55 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
title: Implementation Notes
|
|
3
|
-
permalink: /docs/implementation/
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Implementation
|
|
7
|
-
|
|
8
|
-
For the purpose of maintainability, several internal flows are documented here.
|
|
9
|
-
|
|
10
|
-
## Message Processing
|
|
11
|
-
|
|
12
|
-
When a new message is received by an adapter, a new Message object is constructed and passed to `robot.receive` (async). `robot.receive` then attempts to execute each Listener in order of registration by calling `listener.call` (async), passing in the Listener Middleware stack. `listener.call` first checks to see if the listener matches (`match` method, sync), and if so, calls `middleware.execute` (async) on the provided middleware.
|
|
13
|
-
|
|
14
|
-
`middleware.execute` calls each middleware in order of registration. Middleware can either continue forward (call `next`) or abort (call `done`). If all middleware continues, `middleware.execute` calls `next` (the `listener.call` callback). If any middleware aborts, `middleware.execute` calls `done` (which eventually returns to the `robot.receive` callback).
|
|
15
|
-
|
|
16
|
-
`middleware.execute` `next` returns to `listener.call`, which executes the matched Listener's callback and then calls the `robot.receive` callback.
|
|
17
|
-
|
|
18
|
-
Inside the `robot.receive` processing loop, `message.done` is checked after each `listener.call`. If the message has been marked as done, `robot.receive` returns. This correctly handles asynchronous middleware, but will not catch an asynchronous set of `message.done` inside the listener callback (which is expected to be synchronous).
|
|
19
|
-
|
|
20
|
-
If no listener matches the message (distinct from setting `message.done`), a CatchAllMessage is created which wraps the original message. This new message is run through all listeners again testing for a match. `robot.catchAll` creates a special listener that only matches CatchAllMessages.
|
|
21
|
-
|
|
22
|
-
## Listeners
|
|
23
|
-
|
|
24
|
-
Listeners are registered using several functions on the `robot` object: `hear`, `respond`, `enter`, `leave`, `topic`, and `catchAll`.
|
|
25
|
-
|
|
26
|
-
A listener is used via its `call` method, which is responsible for testing to see if a message matches (`match` is an abstract method) and if so, executes the listener's callback.
|
|
27
|
-
|
|
28
|
-
Listener callbacks are assumed to be synchronous.
|
|
29
|
-
|
|
30
|
-
## Middleware
|
|
31
|
-
|
|
32
|
-
There are two primary entry points for middleware:
|
|
33
|
-
|
|
34
|
-
1. `robot.listenerMiddleware` - registers a new piece of middleware in a global array
|
|
35
|
-
2. `middleware.execute` - executes all registered middleware in order
|
|
36
|
-
|
|
37
|
-
## Persistence
|
|
38
|
-
|
|
39
|
-
### Brain
|
|
40
|
-
|
|
41
|
-
Hubot has a memory exposed as the `robot.brain` object that can be used to store and retrieve data.
|
|
42
|
-
Furthermore, Hubot scripts exist to enable persistence across Hubot restarts.
|
|
43
|
-
`hubot-redis-brain` is such a script and uses a backend Redis server.
|
|
44
|
-
|
|
45
|
-
By default, the brain contains a list of all users seen by Hubot.
|
|
46
|
-
Therefore, without persistence across restarts, the brain will contain the list of users encountered so far, during the current run of Hubot. On the other hand, with persistence across restarts, the brain will contain all users encountered by Hubot during all of its runs. This list of users can be accessed through `hubot.brain.users()` and other utility methods.
|
|
47
|
-
|
|
48
|
-
### Datastore
|
|
49
|
-
|
|
50
|
-
Hubot's optional datastore, exposed as the `robot.datastore` object, provides a more robust persistence model. Compared to the brain, the datastore:
|
|
51
|
-
|
|
52
|
-
1. Is always (instead of optionally) backed by a database
|
|
53
|
-
2. Fetches data from the database and stores data in the database on every request, instead of periodically persisting the entire in-memory brain.
|
|
54
|
-
|
|
55
|
-
The datastore is useful in cases where there's a need for greater reassurances of data integrity or in cases where multiple Hubot instances need to access the same database.
|
package/docs/index.md
DELETED
|
@@ -1,125 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
permalink: /docs/
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
## Getting Started With Hubot
|
|
6
|
-
|
|
7
|
-
You will need [node.js and npm](https://docs.npmjs.com/getting-started/installing-node). Once those are installed, we can install the hubot generator:
|
|
8
|
-
|
|
9
|
-
% npm install -g yo generator-hubot
|
|
10
|
-
|
|
11
|
-
This will give us the `hubot` [yeoman](http://yeoman.io/) generator. Now we
|
|
12
|
-
can make a new directory, and generate a new instance of hubot in it. For example, if
|
|
13
|
-
we wanted to make a bot called myhubot:
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
% mkdir myhubot
|
|
17
|
-
% cd myhubot
|
|
18
|
-
% yo hubot
|
|
19
|
-
|
|
20
|
-
At this point, you'll be asked a few questions about who is creating the bot,
|
|
21
|
-
and which [adapter](adapters.md) you'll be using. Adapters are hubot's
|
|
22
|
-
way of integrating with different chat providers.
|
|
23
|
-
|
|
24
|
-
If you are using git, the generated directory includes a .gitignore, so you can
|
|
25
|
-
initialize and add everything:
|
|
26
|
-
|
|
27
|
-
% git init
|
|
28
|
-
% git add .
|
|
29
|
-
% git commit -m "Initial commit"
|
|
30
|
-
|
|
31
|
-
If you'd prefer to automate your hubot build without being interactively
|
|
32
|
-
prompted for its configuration, you can add the following options
|
|
33
|
-
to the `yo hubot` command to do so:
|
|
34
|
-
|
|
35
|
-
| Option | Description |
|
|
36
|
-
|:--------------------------------------------|:-------------------------------------------------------|
|
|
37
|
-
| `--owner="Bot Wrangler <bw@example.com>"` | Bot owner, e.g. "Bot Wrangler <bw@example.com>" |
|
|
38
|
-
| `--name="Hubot"` | Bot name, e.g. "Hubot" |
|
|
39
|
-
| `--description="Delightfully aware robutt"` | Bot description, e.g. "Delightfully aware robutt" |
|
|
40
|
-
| `--adapter=campfire` | Bot adapter, e.g. "campfire" |
|
|
41
|
-
| `--defaults` | Declare all defaults are set and no prompting required |
|
|
42
|
-
|
|
43
|
-
You now have your own functional hubot! There's a `bin/hubot`
|
|
44
|
-
command for convenience, to handle installing npm dependencies, loading scripts,
|
|
45
|
-
and then launching your hubot.
|
|
46
|
-
|
|
47
|
-
Note: Hubot can use Redis to persist data, so before you can start hubot on your own computer, if you want to persist data, then you should have Redis running on your machine accessible via `localhost`. Then, ensure that `hubot-redis-brain` is listed in `external-scripts.json` as an `Array` of module names (e.g. `['hubot-redis-brain']`) or an `object` where the key is the name of the module (e.g. `{'hubot-redis-brain': 'some arbitrary value'}`) where the value of the property in the object is passed to the module function as the second argument. The first argument being the hubot Robot instance.
|
|
48
|
-
|
|
49
|
-
% bin/hubot
|
|
50
|
-
Hubot>
|
|
51
|
-
|
|
52
|
-
This starts hubot using the [shell adapter](./adapters/shell.md), which is mostly useful for development. Make note of the name in the `hubot>` prompt; this is the name your hubot will respond to with commands. If the prompt reads `myhubot>` then your commands must start with `myhubot <command>`.
|
|
53
|
-
|
|
54
|
-
For example, to list available commands:
|
|
55
|
-
|
|
56
|
-
% bin/hubot
|
|
57
|
-
myhubot> myhubot help
|
|
58
|
-
myhubot> Shell: myhubot adapter - Reply with the adapter
|
|
59
|
-
myhubot animate me <query> - The same thing as `image me`, except adds a few parameters to try to return an animated GIF instead.
|
|
60
|
-
myhubot echo <text> - Reply back with <text>
|
|
61
|
-
myhubot help - Displays all of the help commands that Hubot knows about.
|
|
62
|
-
myhubot help <query> - Displays all help commands that match <query>.
|
|
63
|
-
myhubot image me <query> - The Original. Queries Google Images for <query> and returns a random top result.
|
|
64
|
-
myhubot map me <query> - Returns a map view of the area returned by `query`.
|
|
65
|
-
myhubot mustache me <url|query> - Adds a mustache to the specified URL or query result.
|
|
66
|
-
myhubot ping - Reply with pong
|
|
67
|
-
myhubot pug bomb N - get N pugs
|
|
68
|
-
myhubot pug me - Receive a pug
|
|
69
|
-
myhubot the rules - Make sure hubot still knows the rules.
|
|
70
|
-
myhubot time - Reply with current time
|
|
71
|
-
myhubot translate me <phrase> - Searches for a translation for the <phrase> and then prints that bad boy out.
|
|
72
|
-
myhubot translate me from <source> into <target> <phrase> - Translates <phrase> from <source> into <target>. Both <source> and <target> are optional
|
|
73
|
-
ship it - Display a motivation squirrel
|
|
74
|
-
|
|
75
|
-
You almost definitely will want to change your hubot's name to add character. bin/hubot takes a `--name`:
|
|
76
|
-
|
|
77
|
-
% bin/hubot --name sam
|
|
78
|
-
sam>
|
|
79
|
-
|
|
80
|
-
Your hubot will now respond as `sam`. This is
|
|
81
|
-
case-insensitive, and can be prefixed with `@` or suffixed with `:`. These are equivalent:
|
|
82
|
-
|
|
83
|
-
SAM help
|
|
84
|
-
sam help
|
|
85
|
-
@sam help
|
|
86
|
-
sam: help
|
|
87
|
-
|
|
88
|
-
## Scripts
|
|
89
|
-
|
|
90
|
-
Hubot's power comes through scripts. There are hundreds of scripts written and maintained by the community. Find them by searching the [NPM registry](https://www.npmjs.com/browse/keyword/hubot-scripts) for `hubot-scripts <your-search-term>`. For example:
|
|
91
|
-
|
|
92
|
-
```
|
|
93
|
-
$ npm search hubot-scripts github
|
|
94
|
-
NAME DESCRIPTION
|
|
95
|
-
hubot-deployer Giving Hubot the ability to deploy GitHub repos to PaaS providers hubot hubot-scripts hubot-gith
|
|
96
|
-
hubot-gh-release-pr A hubot script to create GitHub's PR for release
|
|
97
|
-
hubot-github Giving Hubot the ability to be a vital member of your github organization
|
|
98
|
-
…
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
To use a script from an NPM package:
|
|
102
|
-
|
|
103
|
-
1. Run `npm install --save <package-name>` to add the package as a dependency and install it.
|
|
104
|
-
2. Add the package to `external-scripts.json`.
|
|
105
|
-
3. Run `npm home <package-name>` to open a browser window for the homepage of the script, where you can find more information about configuring and installing the script.
|
|
106
|
-
|
|
107
|
-
You can also put your own scripts under the `scripts/` directory. All scripts (files ending with either `.js` or `.mjs`) placed there are automatically loaded and ready to use with your hubot. Read more about customizing hubot by [writing your own scripts](scripting.md).
|
|
108
|
-
|
|
109
|
-
## Adapters
|
|
110
|
-
|
|
111
|
-
Hubot uses the adapter pattern to support multiple chat-backends. Here is a [list of available adapters](adapters.md), along with details on how to configure them.
|
|
112
|
-
|
|
113
|
-
## Deploying
|
|
114
|
-
|
|
115
|
-
You can deploy hubot to Heroku, which is the officially supported method. Additionally you are able to deploy hubot to a UNIX-like system or Windows. Please note the support for deploying to Windows isn't officially supported.
|
|
116
|
-
|
|
117
|
-
* [Deploying Hubot onto Azure](./deploying/azure.md)
|
|
118
|
-
* [Deploying Hubot onto Bluemix](./deploying/bluemix.md)
|
|
119
|
-
* [Deploying Hubot onto Heroku](./deploying/heroku.md)
|
|
120
|
-
* [Deploying Hubot onto Unix](./deploying/unix.md)
|
|
121
|
-
* [Deploying Hubot onto Windows](./deploying/windows.md)
|
|
122
|
-
|
|
123
|
-
## Patterns
|
|
124
|
-
|
|
125
|
-
Using custom scripts, you can quickly customize Hubot to be the most life embettering robot he or she can be. Read [docs/patterns.md](patterns.md) for some nifty tricks that may come in handy as you teach your hubot new skills.
|