austinpray / kaori

I'm a silly slack bot!

カオリ

Hi there! I'm Kaori! I'm a slack bot with functionality that ranges from “useless” to “pretty neat”.

Plugins

My features are implemented as plugins. They can be enabled, disabled, featured flagged independently.

ping

My "hello world" plugin. If you say "ping", I'll say "pong".

Gacha card game

Create, collect, battle gacha cards.

Kkreds

A virtual slack currency.

clap ...

This 👏 is 👏 probably 👏 the 👏 most 👏 obnoxious 👏 plugin.

kaori clap --help for more options.

utility plugins

• User management

Development

I'm kinda easy to get running. Development and production deployment is all done with Docker. Make sure you have Docker installed and running on your system.

The most difficult part of this whole thing is literally just filling in the environment variables. Please PR this document or the .env.example file to make this easier for people who come after you.

Run me

1. You should probably create your own bot testbed slack if you don't already have one. https://slack.com/create
2. Create a slack app and deploy it to your testbed slack
3. You need create a .env file with all the necessary values. Easiest way to do this is to cp .env.example .env and then replace the bogus values with real values.
4. Run make to build all the containers
5. docker-compose run --rm worker alembic upgrade head will create the database for you
6. docker-compose up will start me up! My web interface runs at http://localhost:8000 and my API runs at http://localhost:8001

We aren't out of the woods yet. Now we have to let slack make requests to our API.

1. Install ngrok or do something that will allow you to expose your local API endpoint to the internet.
2. Go to Your Apps and under your bot under "Event Subscriptions" enter your api url. The path should be: /slack/events
3. If you are using ngrok you can inspect the requests from slack at http://127.0.0.1:4040

NOW you should be up and running.

Development / Debug mode

If you want:

• Your code to automatically reload when changed
• Debugger friendly settings (long timeouts, no concurrency)

docker-compose -f docker-compose.yml -f dev.docker-compose.yml up

Note that this deviates from production quite a bit. You should still test PRs using the non-debug docker-compose.

You can easily set a debugger breakpoint now.

docker ps
# look for your desired container ID
docker attach $YOUR_CONTAINER_ID

Set breakpoints in your file.

breakpoint()

You should get a pdb shell in your attached TTY. Exit your attached shell with CTRL-p CTRL-q. More info on docker attach. Note that if you are running docker-compose from IntelliJ it has a nice GUI for attaching a shell to a running container without having to copy IDs around and such.

Tests

Test coverage is reported to Codecov.

To run the tests:

make test

or

docker-compose run test

If you want an interactive shell to run tests in:

docker-compose run test bash -l

Deployment

In general, I am not too picky about where or how I am deployed. All my services are twelve-factor apps. So they should be easy to run anywhere!

I currently run inside a Kubernetes cluster as a set of deployments. I manage continuous delivery and the state of the Kubernetes cluster GitOps-style through fluxcd. My production GitOps setup is available over on the gitops branch.