Skip to content

Refactor Discord bot to use dedicated service with profiles#34

Merged
steezeburger merged 6 commits into
mainfrom
claude/discord-bot-auto-restart-U1jk0
May 8, 2026
Merged

Refactor Discord bot to use dedicated service with profiles#34
steezeburger merged 6 commits into
mainfrom
claude/discord-bot-auto-restart-U1jk0

Conversation

@steezeburger
Copy link
Copy Markdown
Owner

Summary

Refactored the Discord bot deployment to use a dedicated Docker Compose service with profiles instead of running it as a command on the web container. This improves service isolation, management, and enables independent scaling.

Key Changes

  • docker-compose.yml: Added a new bot service with profile ["bot"] that:

    • Builds from the same Dockerfile as the web service
    • Runs the start_discord_bot management command
    • Mounts the same volumes and depends on the database
    • Configured with restart: unless-stopped for automatic recovery
    • Uses environment variables for PostgreSQL host and logs directory
  • justfile: Simplified bot management commands:

    • stop-discord-bot: Changed from container inspection logic to docker compose --profile bot stop bot
    • start-discord-bot: Changed from docker compose run to docker compose --profile bot up -d bot with auto-restart capability
    • restart-discord-bot: Simplified to use docker compose --profile bot up -d --force-recreate bot
    • update-oscarr: Updated build command to include both web and bot services with profile flag

Implementation Details

  • The bot service uses Docker Compose profiles to keep it optional and separate from the default services
  • The dedicated service approach provides better container lifecycle management and clearer separation of concerns
  • Auto-restart behavior is now built into the service configuration rather than relying on manual management
  • All bot management operations now use consistent docker compose --profile bot syntax

https://claude.ai/code/session_01RJrZb4X5Ywuzq2SjeFXgN1

claude added 6 commits May 8, 2026 18:07
The bot was launched via `docker compose run -d --rm`, which strips the
service-level restart policy and removes the container on exit. When the
host hits memory pressure and the OOM killer takes the bot, it stays
gone. Promote it to a real compose service (gated behind the `bot`
profile so it doesn't start with `dcp-up-all`) and switch the justfile
recipes to `up -d` / `stop` so Docker actually restarts it.
It was only needed because the old run-based launch produced an
unlabeled container that had to be matched by inspecting Cmd. Now that
the bot is a managed compose service, `docker compose stop bot` does
the job directly.
Container names default to <project>-<service>-N, where the project
defaults to the parent directory (`django-app`). Pinning it to
`oscarr` produces `oscarr-bot-1` etc. without redundant service
prefixes.

Migration: existing containers/networks under the old `django-app`
project are orphaned. Run `docker compose down` against them once,
then bring services back up under the new project. The
`oscarr_postgres` volume is external and named, so data is unaffected.
Mirrors the brainspread deploy pattern: a workflow_run trigger waits for
the CI workflow to finish on main, and on success SSHes into the VPS
and runs `just update-oscarr`. Requires the following to be configured
on the repo's `ci` environment:

- secret DO_SSH_HOST: VPS hostname
- secret DO_SSH_USER: SSH user
- secret DO_SSH_KEY:  SSH private key
- variable DO_PROD_DIR: absolute path to the oscarr checkout on the VPS
Restructures CI to mirror brainspread's two-phase pattern:

1. Native fast-fail: ruff format check, ruff lint, pyright type check.
2. Docker-based: bake build with GHA layer cache, migrate, `manage.py
   check --deploy`, run tests inside the web container.

Also:
- renames the workflow to "Lint and Test" so deploy.yml's
  workflow_run reference matches brainspread byte-for-byte
- adds a concurrency group so superseded runs cancel
- pins python via `python-version-file` rather than a hardcoded 3.12
- drops the GH Actions postgres service in favor of compose's db
- adds a `copy-env` justfile recipe so the CI step matches brainspread

Kept oscarr-specific bits: ruff format (not Black), pyright type check
(brainspread has none), no Node/Prettier (no JS to lint here).
`Prepare .env for CI` becomes `Copy environment file` +
`Generate secret key`. `Create volumes and bring up db` becomes
`Create volumes` + `Start database`. The DB-up step is unique to
oscarr's flow (brainspread folds it into its just recipes); the rest
now mirror brainspread byte-for-byte.
@steezeburger steezeburger merged commit b00241c into main May 8, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants