[Feature]: Publish official Docker images (GHCR) on release

[cmasia]

Problem or use case

roam-code already ships a well-structured Dockerfile (´python:3.12-slim-bookworm´, non-root user, OCI labels, healthcheck) and documents a local docker build path in the README. There is no official pre-built image on GHCR or Docker Hub, so every user who prefers containers must clone the repo and build from source.

This adds friction for:

• users who prefer docker run over pip/pipx/uv (my deployment case)
• CI/CD pipelines that want a stable, versioned image without building on every job
• environments where installing Python tooling is restricted or undesirable

An unofficial image exists (letiemble/roam-code), but it is not maintained by the project and can drift from releases.

Proposed solution

1. Add a GitHub Actions workflow that builds and pushes the existing Dockerfile to GitHub Container Registry on every tagged release (e.g. v*). Suggested tags:

• ghcr.io/cranot/roam-code:latest
• ghcr.io/cranot/roam-code:<semver> (e.g. 14.0.0)
• optionally ghcr.io/cranot/roam-code:<major> and <major>.<minor>

2. Workflow outline:

• Trigger on release / tag v*
• Login to ghcr.io with ${{ secrets.GITHUB_TOKEN }}
• Build with docker/build-push-action (multi-platform linux/amd64, linux/arm64 if feasible)
• Push the tags above
• Optionally attach SBOM / provenance attestations

3. Update the README “Alternate install methods + Docker” section with pull/run examples, e.g.:

docker pull ghcr.io/cranot/roam-code:latest
docker run --rm -v "$PWD:/workspace" ghcr.io/cranot/roam-code index
docker run --rm -v "$PWD:/workspace" ghcr.io/cranot/roam-code health

4. Keep the existing local-build instructions as a fallback.

5. (Optional) Enable package visibility = public and link the package to the repository so it appears under the repo’s Packages tab.

I am happy to open a follow-up PR with the workflow + README changes if this direction is acceptable.

Alternatives considered

• Local build only (status quo) — works, but forces every consumer to rebuild.
• Docker Hub instead of / in addition to GHCR — possible; GHCR is the lowest-friction option because authentication and permissions are already available via GITHUB_TOKEN.
• Rely on the existing unofficial image — not ideal, image is pretty old.
• Publish only on major releases — possible compromise, but tagging every release keeps the image in sync with PyPI.

Category

CI/CD Integration

Additional context

Happy to adjust scope (single-arch first, documentation-only first, etc.) based on maintainer preference.