CodeyBot

CodeyBot is a Discord bot in the CSC server. CodeyBot can do a bunch of different things, from administrative actions to information and games.

Historical Note

We used to have a team dedicated to developing CodeyBot within the Organizing Committee, called CodeyBot Developer team. However, as of Fall 2025, in order to make the CSC Committee more efficient and organized, CodeyBot Developer team has been dissolved. The responsibilities of maintaining and developing CodeyBot now falls in the hands of Termcom.

Contribution

The repo for CodeyBot is public, so you don't have to be a member of Termcom to develop CodeyBot (of course only Termcom has access to perform maintenance). Whether you're in Termcom or just an enthusiastic individual, please visit https://github.com/uwcsc/codeybot. It should have all the instructions for you to contribute to CodeyBot.

Management/Maintenance (For Termcom only)

Now here comes the fun part. It's fun because there has never been a single documentation on this stuff. But I didn't enjoy that kind of fun. So please read this.

Hosting

We have 3 servers to host CodeyBot for different purposes. All 3 servers are CSC Cloud VMs. Ask the current Termcom Lead/Sysadmin for access to the VMs. These 3 servers are:

• codey-staging: for staging, i.e. verifying that the main branch is behaving properly before shipping to production.
• codey-prod: for production, i.e. the CodeyBot currently sitting in the CSC server.
• codey-bootcamp: a different version of CodeyBot tailored for CSC Bootcamp events (which happens every now and then).

Note: there are discussions to move CodeyBot to caffeine because Cloudstack is not kind. As of this writing, this still remains a discussion.

Structure

For the sake of brevity, let environment be a variable, where environment is one of production, staging, bootcamp.

On the corresponding VM, go to ~/codey/{environment}. In this directory, when you ls -al, you should see 4 things:

• .env: This file contains the secret tokens needed for CodeyBot to work properly. It should not be changed (there's literally nothing to update there).
• db/: This directory contains a SQLite database used by CodeyBot. Do not let this database disappear, or you're not gonna find any good reasons to explain to CSC server members how their coins just vanished into thin air.
• docker-compose.yml: This file allows you to start the bot with docker-compose up -d and stop the bot with docker-compose down. Note that this file is the same as codeybot/docker/{environment}/docker-compose.yml. For reasons I'll explain later, the docker-compose.yml in the VM is manually synced to the one in the repo.
• logs/: This directory contain the logs from the Docker container. Not much importance.

Now, when you docker ps -a, you should see 2 containers:

• codey-{environment}: The container that runs CodeyBot. It should not be down (if it does, it should auto restart).
• watchtower: The magic that allows CodeyBot to be automatically updated with the latest changes. It should not be down (if it does, it should auto restart). For reference, this is the command that ran the container the first time. Also, you can learn more about Watchtower here https://github.com/containrrr/watchtower.

docker run -d \
  --name watchtower \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  codey-{environment} \
  --interval 30 \
  --cleanup \
  --debug

CI/CD pipeline

We consider 2 different situations:

• Staging: Whenever the main branch changes, it triggers the corresponding code in .github/workflows/build.yml that builds the image and uploads it to Docker Hub. Watchtower looks out for image changes every 30 seconds. If the image is updated, Watchtower stops the current CodeyBot container, pulls the latest image, rebuilds the container and starts it up again.
• Production: Whenever a release is made on GitHub, it triggers the corresponding code in .github/workflows/build.yml that builds the image and uploads it to Docker Hub. Watchtower looks out for image changes every 30 seconds. If the image is updated, Watchtower stops the current CodeyBot container, pulls the latest image, rebuilds the container and starts it up again.

Due to the use of Watchtower, the docker-compose.yml to build the CodeyBot container cannot be automatically synced (without making things unnecessarily messy). In the past, we used GitHub SSH Action to sync everything (Docker image, docker-compose.yml, .env and rebuilding container). However, at some point, the SSH broke, and we never figured out why. And the SSH-related creds are stored as GitHub secrets, and I have zero idea which one means what. So I just went with Watchtower (it's a lot more reliable anyways, just need to manually update 1 file).