Gitbot

The problem

When several people and AI tools are all pushing changes, it’s easy to lose track of what changed and why. We wanted one shared place to see it.

What we built

• A live feed of pushes, pull requests, issues and releases, naming which project each change touched
• A searchable history of every event, stored in SQLite
• Slash commands for projects, history, search, open pull requests, stats and access
• A scheduled digest of the most changed projects
• A daily database backup, and a warning before the GitHub token expires

Decisions worth explaining

Check every webhook

Anything can send a request to a public address, so the bot verifies GitHub’s signature before trusting it, and stores redelivered events only once.

Few moving parts

SQLite is built into Node, and Node runs the TypeScript directly, so there’s no database server or build step to look after.

Least access

The GitHub token is read-only and limited to one repository, and the Discord bot asks for only the permissions it needs.

Plan for being offline

At every start, the bot fetches what it missed and posts one summary, so a restart doesn’t leave a hole in the history.

What went wrong

Running it from a laptop, GitHub reaches the bot through a temporary tunnel address that changes on restart. When the address went stale, every delivery failed and the feed went quiet, and nothing warned us. The catch-up recovered the missed changes after a restart, but the real fix is a permanent address, plus a warning when no events have arrived for a while.

What we tested

The tests cover parsing GitHub events, signature checks, the database, access control, catching up and maintenance. They run with a type check on every pull request.