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.
Add Guri to your mix.exs dependencies:
defp deps do
[{:guri, "~> 0.2.1"}]
endAdd Guri to your mix.exs applications:
def application do
[applications: [:guri]]
endAnd run:
mix deps.get
In your config/config.exs add the following config:
# 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 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 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:
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
endNon-Supervised handlers don't need to keep state. They are just simple modules.
Example of MyApp.Stat handler:
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
endmix test
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent