- Bagelbot GitLab
- Bagelbot Deployment
- Bagelbot Slack Management
- Slack Visual Message Builder
- Bagelbot Container Registry
- Bagelbot Deployment Management
- Recommended DB Viewer
- or use
brew install --cask mongodb-compassif on a mac withbrew.shinstalled
- or use
Running an instance of bagelbotdev/api requires the following enviornment variables specified, typically in a top-level .env file.
| Name | Purpose |
|---|---|
MONGO_URL |
The mongodb connection string with credentials specified |
COIN_ENDPOINT |
The coin api endpoint to interact with. Typically, this is http://bryxcoin01.csh.rit.edu |
SLACKBOT_WEBHOOK |
The webhook to interact with when sending messages to slack channels |
Slack @tyler with any questions or for access credentials.
| Sector | Technology | Justification |
|---|---|---|
| API Language | typescript | Type safety and seamless integration with other technologies in this project |
| API Framework | express | Middleware-based routing model, plus general familiarity |
| Bagelbot Database | mongodb | Mostly to spite @galen.guyer, but also familiarity with the mongoose modeling tool. Bagelbot implements a fixed-schema data set, despite mongodb. |
| GQL Client | urql | Lightweight alternative to apollo. Limited gql functionality is needed for this project |
| Endpoint | Description |
|---|---|
GET / |
Redirects to the #bagels channel in bryx slack |
GET /kube |
Redirects to the kubernetes dashboard for bagelbot. Note that this requires kubectl proxy to be running on the developer's machine, as well as a ~/.kube/config that grants access to the underlying deployed api instance. |
GET /dashboard |
Redirects to the bagelbot dashboard |
GET /healthcheck |
Flexible endpoint designed for confirming a 200 response |
POST /interaction |
Handles any slack interaction performed (such as clicking buttons in forms, etc) |
POST /event |
Handles scoped slack events performed (such as @BagelBot mentions, etc) |
POST /slash/<command> |
Handles the corresponding slash command, such as /register, /pay, etc |
GET /v1/users |
Returns the first name, last name, and slack id of all registered users |
GET /v1/tabs |
Get the opener's fullname, opened at timestamp, cartGuid, and closed status of all past and current tabs |
GET /v1/coin |
Returns the first name, last name, and coin balance for each registed user |
| Path | Purpose |
|---|---|
@types/ |
Exposes non-scoped type declarations to be used anywhere in the project |
gql/ |
Prebuilt GQL queries for fetching data from the Balsam Bagel ToastTab GQL endpoint |
src/balsam |
Logic relating to interacting with Balsam Bagels (and their gql endpoint) |
src/db |
Models and Schemas, as well as logic wrappers for interacting with the Bagelbot DB |
src/coin |
Logic for interacting with the underlying coin blockchain |
src/db/models |
Mongoose model definitions. Should contain a one-to-one file mapping with the schemas folder |
src/db/schemas |
Mongoose schema definitions, for consumption by the models folder |
src/middlewares |
Express middlewares, such as validating registration, etc |
src/routes |
Contains all the routers to be used by the express app. Each folder / file within this directory correspond to a part of the path to be handled. For example, src/routes/slash/menu.ts should be set up to handle the /slash/menu request, and so on. |
slack/ |
Resources for interacting with Slack |
slack/blockkit/prefab |
Static blockkit definitions. See the Slack Visual Message Builder for context |
slack/blockkit/mappers |
Functions that, given a fixed input, returns a blockkit message definition. These are the dynamic counterparts to the prefab messages |
The production enviornment is not tied to github CI/CD. The purpose of this, is that often times chagnes need to be tested before committing. In the furture, we may have a speerate bot that acts as a "staging" enviornment, but it is nearly impossible to replicate a staging slack enviornment for development. As such, the production enviornment acts as a staging enviornment.
Production deployment prerequisites:
- The
yarn,kubectl, anddockercli tools are all installed and accessable in$PATH. - Your local container runtime is up.
- You have access to the underlying kubernetes cluster (specifed in your local
~/.kube/config) - You are logged in to the relevant container registry. You can do this with
docker login ghcr.io/bagelbotdev
Once you have confirmed you meet the prereqs, you can deploy the current working version of the codebase to production with yarn rollout which will automatically perform the following steps:
- Build the current version of the codebase into an image tagged with
:latest. - Push the newly created image to the container registry.
- Restartes the kubernetes api deployment which will trigger an image re-pull.
- Executes a healthcheck probe twice a second to check when the deployment is back online. When the response changes from
404 not foundorBad GatewaytoOK, the deployment is complete!
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent