Guri
========
Guri was created to automate tasks and let people know about what's happening. It is a bot system that uses chat messages as commands. You can easily write command handlers to automate anything you want. Nice things you can automate (but not limited to):
* Deploy a project to a specific environment (e.g. production, staging)
* Scale a specific environment up/down
* Enable or Disable features (feature toggle)
* Create/close a Github issue
Guri is not only limited to command handling. It can also be used to automatically post useful information to a chat room.
Usage
-----
Add Guri to your `mix.exs` dependencies:
```elixir
defp deps do
[{:guri, "~> 0.2.1"}]
end
```
Add Guri to your `mix.exs` applications:
```elixir
def application do
[applications: [:guri]]
end
```
And run:
```
mix deps.get
```
### Configuration
In your `config/config.exs` add the following config:
```elixir
# Bot adapter (currently only Slack is supported)
config :guri, :adapter, Guri.Adapters.Slack
# Configure your Slack bot
config :guri, :slack,
bot_name: "BOT_NAME", # the one you created in Slack
channel_name: "CHANNEL_NAME", # the name of the channel the bot is in
url: "https://slack.com/api",
token: "TOKEN" # Token from Slack (e.g.: abced-00000000-AASDADzxczxcasd)
# Command Handlers you want to use
#
# MyApp.Deploy is a supervised handler
# MyApp.Stat is a non-supervised handler
#
config :guri, :handlers, %{"deploy" => {:supervised, MyApp.Deploy},
"stat" => MyApp.Stat}
```
With the described configuration, every time someone sends a `deploy` command, `MyApp.Deploy` will receive the command information. The same happens to the `stat` command and `MyApp.Stat` module.
### Command Handlers
Command handlers are responsible for processing the commands published in a chat room. Using the previous example, `MyApp.Deploy` and `MyApp.Stat` are command handlers. Each command handler is able to handle a single command. A handler can be of two types:
#### Supervised
Supervised handlers need to keep state. You will probably use an `Agent` or `GenServer` in order to keep the state. These handlers will be started as part of the application supervision three. When defining the handler in the `config.exs` file, it uses a tuple like `{:supervised, MODULE_NAME}`.
Example of `MyApp.Deploy` handler:
```elixir
defmodule MyApp.Deploy do
use Guri.Handler
def start_link do
Agent.start_link(fn -> [] end, name: __MODULE__)
end
def handle_command(%{name: "deploy", args: []}) do
send_message("Deploying all projects to production")
end
def handle_command(%{name: "deploy", args: [project]}) do
send_message("Deploying `#{project}` to production")
end
def handle_command(%{name: "deploy", args: [project, "to", env]}) do
send_message("Deploying `#{project}` to `#{env}`")
end
def handle_command(_) do
send_message("Sorry, I couldn't understand what you want to deploy")
end
end
```
#### Non-Supervised
Non-Supervised handlers don't need to keep state. They are just simple modules.
Example of `MyApp.Stat` handler:
```elixir
defmodule MyApp.Stat do
use Guri.Handler
def handle_command(%{name: "stat", args: []}) do
stats = StatService.get_and_process_stats()
send_message(stats)
end
def handle_command(_) do
send_message("Sorry, I couldn't understand the stat you are looking for")
end
end
```
### Run Test
```
mix test
```