View source for 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 CSC 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.

=== Discord Mod for Ban Appeal ===
If you haven't noticed already, CSC Committee has Discord Moderators. And like it or not, they need to ban people from CSC server quite frequently. Whenever a server member is banned, they get DM'ed by CodeyBot on why they were banned and who they could get in touch for further details. This who is usually the team lead of the Discord Moderators. And they might change, from term to term. As such, <b>at the beginning of every term</b>, make sure that the variable <code>MOD_USER_ID_FOR_BAN_APPEAL</code> is set to the Discord user ID of the right person. The variable can be found in <code>config/production/vars.json</code> in the repo.

=== 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:
* <code>codey-staging</code>: for staging, i.e. verifying that the <code>main</code> branch is behaving properly before shipping to production.
* <code>codey-prod</code>: for production, i.e. the CodeyBot currently sitting in the CSC server.
* <code>codey-bootcamp</code>: a different version of CodeyBot tailored for CSC Bootcamp events (which happens every now and then).

Note: there are discussions to move CodeyBot to <code>caffeine</code> because CloudStack is not kind. As of this writing, this still remains a discussion.

=== VM Access ===
I told you that CodeyBot is hosted on CloudStack. What I did not tell you is that CloudStack is broken. More specifically, you cannot add your own SSH key from the web interface, nor can you access the console from the web interface.

As such, until CodeyBot is migrated away from CloudStack, make sure there is <b>at least 1 person</b> who already has access to the VMs so that they can give you access to the VMs. Just give them your public SSH key and they can add you to the VMs.

=== Structure ===
For the sake of brevity, let <code>environment</code> be a variable, where <code>environment</code> is one of <code>production</code>, <code>staging</code>, <code>bootcamp</code>.

On the corresponding VM, go to <code>~/codey/{environment}</code>. In this directory, when you <code>ls -al</code>, you should see 4 things:
* <code>.env</code>: This file contains the secret tokens needed for CodeyBot to work properly. It should not be changed (there's literally nothing to update there).
* <code>db/</code>: This directory contains a SQLite database used by CodeyBot. <b>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.</b>
* <code>docker-compose.yml</code>: This file allows you to start the bot with <code>docker-compose up -d</code> and stop the bot with <code>docker-compose down</code>. Note that this file is the same as <code>codeybot/docker/{environment}/docker-compose.yml</code>. For reasons I'll explain later, the <code>docker-compose.yml</code> in the VM is manually synced to the one in the repo.
* <code>logs/</code>: This directory contain the logs from the Docker container. Not much importance.

Now, when you <code>docker ps -a</code>, you should see 2 containers:
* <code>codey-{environment}</code>: The container that runs CodeyBot. It should not be down (if it does, it should auto restart).
* <code>watchtower</code>: 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.
<pre>
docker run -d \
  --name watchtower \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  codey-{environment} \
  --interval 30 \
  --cleanup \
  --debug
</pre>

=== CI/CD pipeline ===
We consider 2 different situations:
* Staging: Whenever <b>the <code>main</code> branch changes</b>, it triggers the corresponding code in <code>.github/workflows/build.yml</code> 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 <b>a release is made on GitHub</b>, it triggers the corresponding code in <code>.github/workflows/build.yml</code> 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 <code>docker-compose.yml</code> 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, <code>docker-compose.yml</code>, <code>.env</code> 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).