Releasing

Releasing

Releases are driven by release-please from Conventional Commits, published to PyPI via Trusted Publishing (OIDC, no stored token), and shipped as a container image to GHCR.

Flow

1. Land changes on main with conventional commits (feat:, fix:, feat!:/BREAKING CHANGE: for majors). release-please maintains a release PR that bumps the version in src/argus/__init__.py + .release-please-manifest.json and updates CHANGELOG.md.
2. Merge the release PR. Branch protection requires status checks, which a release-please PR (authored by GITHUB_TOKEN) does not carry, so merge with admin: gh pr merge <n> --squash --admin.
3. The same workflow run then creates the tag + GitHub Release and, gated on release_created, publishes to PyPI and pushes the Docker image (these live in release-please.yml so they run in the merge-triggered run, avoiding the GITHUB_TOKEN-release-event limitation).

PyPI Trusted Publishing

PyPI matches a trusted publisher on the workflow filename, so register both on pypi.org -> project argus-dpy -> Publishing (owner AstorisTheBrave, repo argus, environment pypi):

• release-please.yml — the automatic path.
• publish.yml — the manual fallback.

The wheel bundles the dashboard SPA (built by the hatch hook with Node) and only subset woff2 fonts; .ttf/.otf/.map are excluded so it stays small.

Manual publish

Actions -> publish -> Run workflow, optionally with a tag (e.g. v0.3.0). Idempotent (skip-existing: true), with attestations.

Docker image

ghcr.io/astoristhebrave/argus:<version> and :latest are built per release from the multi-stage Dockerfile (SPA + wheel + the basic example bot). CI also builds the image without pushing on every PR to validate it. Pin a version tag in production so a mid-development change can never reach a deployment.

docker run -e DISCORD_TOKEN=... -p 9191:9191 ghcr.io/astoristhebrave/argus:latest