- docker-compose.yml: `restart: unless-stopped` so a panic, bad frame or VPS
reboot brings the bot back instead of leaving it dead. Comment explaining why
no healthcheck (slim runtime, no HTTP port).
- Cargo.toml: enable tracing-subscriber's env-filter feature (declared but never
initialised until now).
- main.rs: initialise tracing as the first statement in main(), defaulting to
`info` — serenity/poise/supabase logs now surface, without leaking student IDs
or the service email that the Supabase client emits at `debug`.
- deploy.yml: after `up -d`, assert the container is actually Running 30s later
and dump its logs and fail if not — `up -d` returns 0 on container creation,
not on a working process.
- Dockerfile: pin the builder to rust:1-bookworm to match the bookworm-slim
runtime, removing the trixie/bookworm glibc mismatch.
- README: document the info-level default and the RUST_LOG=debug PII footgun.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017XrE7F9ZuBWdQnS8CZvYDE
* SEC-01: add pull-request CI and stop the deploy leaving DOT_ENV on the VPS
A merge to main runs the merged commit as root on the club VPS through the
self-hosted runner, and this repo has no PR CI, no required review and no
status check.
- .github/workflows/ci.yml: fmt / clippy / build --locked / test on
ubuntu-latest, contents: read, both actions pinned by commit SHA. Never
the VPS.
- deploy.yml: keep push to main, add workflow_dispatch, permissions
contents: read, environment: production, and an if: always() step that
removes the .env the deploy writes into the workspace.
- .dockerignore: keep that .env, target/ and .git out of the build context.
- Dockerfile: --locked on both cargo build --release lines.
environment: production gates nothing until required reviewers are configured
on the environment itself, and the ruleset still requires zero approving
reviews. Both are owner-only and listed in the pull request.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* SEC-01: make cargo fmt and clippy clean so the CI job can go green
The CI workflow added in #5 fails on code that predates it: three files were
unformatted and `cargo clippy --all-targets -- -D warnings` reported 26 errors.
A red check cannot be made a required status check on the protect-main ruleset,
which is what this unblocks.
`cargo fmt --all` over three files, and 26 clippy errors resolved: 18 via
`cargo clippy --all-targets --fix`, the rest by hand. Two fixes uncovered lints
that had been masked (an `unnecessary_unwrap` in info.rs behind the needless
borrow on the line above, and two `unnecessary_to_owned` at the call sites of a
signature that moved from `&String` to `&str`), so 28 fixes for 26 warnings.
Three `#[allow]`s where the only real fix would change a signature or a public
API: `result_large_err` on `AppState::new` (the large variant is
`supabase::Error`, owned by supabase-lib-rs) and `too_many_arguments` on
`log_embed` and on the `embed` slash command.
No behaviour change. src/ only; .github/, Dockerfile, .dockerignore, Cargo.toml
and Cargo.lock are untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* SEC-01: pin actions/checkout in the deploy workflow to a commit SHA
deploy.yml runs on the self-hosted VPS runner with passwordless sudo, so a
mutable tag on this action is a code-execution path onto that host if the tag
is ever moved. Pinned to the commit v4 currently resolves to
(11d5960a326750d5838078e36cf38b85af677262), verified against upstream — this is
the same code the deploy already runs today, not a version bump. ci.yml is on
v7.0.1; the deploy path is deliberately left on v4 so that pinning does not
smuggle a major-version change into a workflow whose only test is a live deploy.
Raised by Codex review of PR #5 as the one unpinned `uses:` in either workflow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
