fix(ci+docker): install from uv.lock — stop resolving dependencies at build time #81

Merged

bvandeusen merged 4 commits from dev into main 2026-07-28 13:04:24 -04:00

Conversation 0 Commits 4 Files Changed 3

+110 -70

4 Commits

Author	SHA1	Message	Date
bvandeusen	1b81310847	fix(docker): build the image from uv.lock too ... The other half of #2194. The runtime stage did `COPY pyproject.toml .` + `pip install .` and never copied uv.lock at all, so the SHIPPED IMAGE resolved its own dependency set — independently of CI and of the lock. CI could be green on one set of versions while the published image ran another, which makes a green run evidence about the tests and not about the artifact. Now: install uv, sync deps from the lock, then sync the project. Split into two syncs so the dependency layer caches on any build that doesn't touch the lock — the same shape CI uses, so image and CI can no longer disagree. `uv sync` installs into /app/.venv rather than the system interpreter, so PATH picks it up for the alembic + hypercorn CMD. The project stays editable, which keeps /app/src authoritative exactly as PYTHONPATH and the frontend-dist copy into src/scribe/static/ already assume. Not built locally (rules #10/#12) — the dev build job verifies it, and `main` already carries a working :latest, so a break here can't strand a deploy.	2026-07-28 13:01:35 -04:00
bvandeusen	a47e1b9c4e	fix(ci): regenerate uv.lock and enforce it with --locked ... Completes the previous two commits. `--frozen` failed run 3007 with `ModuleNotFoundError: No module named 'pgvector'` — the lock wasn't merely stale in its recorded metadata, it was missing a real dependency. pgvector was added to pyproject for the vector-search work and the lock was never regenerated, and nothing noticed because CI resolved from pyproject and never read the lock. The lock has been dead weight for some time. Regenerated with `uv lock` inside a throwaway `ci-python:3.14` container — this workstation has no uv and no pip, and the CI image already carries the right toolchain, so nothing was installed to do it. uv was conservative as promised: pgvector 0.5.0 added, and NOT ONE existing pin moved (verified by diffing name=version pairs across all 106 packages). Both lanes now run `uv sync --locked`, so a dependency edit without a re-lock fails loudly at install rather than resolving around the lock. The check paid for itself on its first run by surfacing the missing pgvector. Also added uv.lock to the workflow's `paths:` filter. It was absent, so a lock-only change — exactly what a dependency bump looks like now — would not have triggered CI at all. Closes the CI half of #2194. The Dockerfile still resolves independently and is tracked there.	2026-07-28 12:58:18 -04:00
bvandeusen	8bab0c762b	fix(ci): use uv sync --frozen — --locked needs a lock this box can't regenerate ... Run 3006 failed at the install step: "The lockfile at `uv.lock` needs to be updated, but `--locked` was provided." The guard was working — the mcp cap edited pyproject, so the lock genuinely is stale, and hand-editing the recorded specifier wasn't enough to satisfy uv's freshness check. Regenerating needs `uv lock`, and this workstation has neither uv nor pip (rule #10 — local Python envs are deliberately absent), so obtaining it would mean pulling a binary from github.com, against rule #3. Not doing that unilaterally. --frozen installs exactly what the lock pins and resolves nothing, which is the whole point of #2194: no dependency can float into a run again. What it gives up is only the staleness check — and a forgotten re-lock surfaces as a loud ImportError, not as a silent version drift, so the failure mode is the tolerable one. Flip to --locked in the same change that runs `uv lock`. Refs #2194.	2026-07-28 12:55:06 -04:00
bvandeusen	ef7ebddadf	fix(ci): install from uv.lock so CI stops resolving dependencies itself ... Closes the reproducibility hole that turned `main` red an hour ago. CI ran `uv pip install -e ".[dev]"`, which resolves from the pyproject constraints and ignores uv.lock completely — so every dependency floated. uv.lock pinned mcp 1.27.2; CI installed the 2.0.0 published mid-session and the identical tree that passed on `dev` failed on `main`. Both Python lanes now run `uv sync --locked --extra dev`. `--locked` also fails when the lock is stale against pyproject, so a dependency change has to go through a deliberate `uv lock` instead of arriving on its own — which also restores the point of the Renovate dashboard-approval flow. Dropped the http-ece install and the setuptools/wheel step that existed only to support it: nothing in src/ or tests/ imports http_ece. It is a leftover from the web-push subsystem removed in the MCP-First pivot, and it was never in pyproject or uv.lock — CI was installing an unused package and carrying a --no-build-isolation workaround for it. Cache key moves from pyproject.toml to uv.lock, since the lock is now what determines the installed set. uv.lock's recorded root requirement updated to match the mcp cap. Edited by hand rather than regenerated: uv isn't installed on this workstation, the resolved mcp 1.27.2 already satisfies `<2`, so no re-resolution is needed — only the staleness check needed satisfying. The Dockerfile still resolves independently (`pip install .`, and it doesn't even copy uv.lock), so the shipped image is not yet covered. Following separately so a build break can't strand `main`. Refs #2194.	2026-07-28 12:50:52 -04:00