Skip to content

fix(docker): correct site-packages path, and build the image in CI - #11

Merged
jqnatividad merged 1 commit into
dathere:mainfrom
jqnatividad:fix-docker-build
Sep 16, 2026
Merged

jqnatividad merged 1 commit into
dathere:mainfrom
jqnatividad:fix-docker-build

Conversation

@jqnatividad

Copy link
Copy Markdown
Collaborator

The image build has been broken since 2026-09-10, and nothing noticed because no
workflow builds it.

The bug

Dockerfile copied /usr/local/lib/python3.11/site-packages from the builder,
but #3 bumped both stages to python:3.14-slim, where packages live under
python3.14. Docker fails a COPY --from whose source does not exist:

ERROR: "/usr/local/lib/python3.11/site-packages": not found

That takes out docker build and docker compose up --build — the Docker path
the README documents — so the only working install route has been the venv one.

Changes

  • Dockerfile:62 copies python3.14/site-packages
  • New blocking docker CI job: builds the image (buildx, GHA layer cache)
    and boots it, requiring /health and /api/v1/health
  • CONTRIBUTING.md gate table and the Serena tech_stack memory record the new
    gate and why it exists

Why the job boots the container instead of only building

The production stage copies site-packages and src/ in separate COPY lines,
so a wrong path can still yield an image that builds and then fails on import.
web.py::include_api_routes also swallows a failed router import as a printed
warning rather than a crash — a build-only check would pass on an image serving
a UI with no API. /api/v1/health is what catches that.

Verified locally

Build succeeds (873MB). Inside the image: Python 3.14.7, site-packages at the
expected path, fastapi/pydantic/langgraph/pandas/nbclient and
data_concierge all import, qsv 22.0.1 present via the /usr/local/bin copy.
Container runs with restarts=0; both health endpoints return 200; no
tracebacks and no router-import warning.

The failure itself was reproduced with a minimal two-stage Dockerfile before
fixing, to confirm the mechanism rather than infer it.

🤖 Generated with Claude Code

The production stage copied /usr/local/lib/python3.11/site-packages, but dathere#3
bumped both stages to python:3.14-slim, where that path does not exist. Docker
fails the instruction rather than skipping it, so every image build has failed
since 2026-09-10 — including `docker compose up --build`, the Docker path the
README documents.

Nothing built the image in CI, which is why it shipped unnoticed for six days.
Add a blocking `docker` job that builds it and boots it, asserting /health and
/api/v1/health. The build alone is not enough: the production stage copies
site-packages and src/ in separate COPY lines, and web.py swallows a failed API
router import as a warning rather than a crash, so only booting the container
catches those.

Verified locally: build succeeds (873MB), image runs Python 3.14.7, deps and
data_concierge import, qsv rides along on the /usr/local/bin copy, and both
health endpoints return 200 with no restarts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jqnatividad
jqnatividad merged commit 9aaa067 into dathere:main Sep 16, 2026
6 checks passed
@jqnatividad
jqnatividad deleted the fix-docker-build branch September 16, 2026 10:36
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.

1 participant