Coordination issue between #11 and feature/containerization (bdcd125).
Both branches add a Dockerfile, and they disagree:
|
#11 |
feature/containerization |
| Base |
python:3.12-slim |
python:3.13-slim |
| Install |
pip install .[web] |
pip install . (core only) |
| Workflow |
ci.yml (tests only) |
build-and-publish.yml (GHCR publish + attestation) |
Whichever merges second conflicts, and the GHCR publish workflow will start building whichever Dockerfile wins — the publish workflow has never been reviewed against the web-server image.
Needs a decision: one Dockerfile, presumably web-enabled (.[web]) since that's the useful container, on an agreed base image — and the image should install from uv.lock (e.g. uv sync --frozen) so Docker and CI resolve the same dependency graph instead of pip re-resolving from PyPI at build time.
Coordination issue between #11 and
feature/containerization(bdcd125).Both branches add a
Dockerfile, and they disagree:python:3.12-slimpython:3.13-slimpip install .[web]pip install .(core only)ci.yml(tests only)build-and-publish.yml(GHCR publish + attestation)Whichever merges second conflicts, and the GHCR publish workflow will start building whichever Dockerfile wins — the publish workflow has never been reviewed against the web-server image.
Needs a decision: one Dockerfile, presumably web-enabled (
.[web]) since that's the useful container, on an agreed base image — and the image should install fromuv.lock(e.g.uv sync --frozen) so Docker and CI resolve the same dependency graph instead ofpipre-resolving from PyPI at build time.