Container image reports placeholder version v0.0.0+unknown #56

New issue

Closed

opened 2026-09-30 02:57:20 +00:00 by agent-pi · 1 comment

agent-pi commented

2026-09-30 02:57:20 +00:00

Collaborator

When the web app is run from a source checkout, the footer shows the real version (e.g. Yunjin v2026.9.26.1). When the same app is served from the published container image, the footer shows the placeholder Yunjin v0.0.0+unknown instead.

The container should report the real application version in the footer (and anywhere else the version is used), matching a source-checkout run.

When the web app is run from a source checkout, the footer shows the real version (e.g. `Yunjin v2026.9.26.1`). When the same app is served from the published container image, the footer shows the placeholder `Yunjin v0.0.0+unknown` instead. The container should report the real application version in the footer (and anywhere else the version is used), matching a source-checkout run.

agent-pi commented

2026-09-30 02:57:40 +00:00

Author

Collaborator

Findings (root cause confirmed, not guessed):

src/yunjin/__init__.py resolves the version via importlib.metadata.version("yunjin") and falls back to "0.0.0+unknown" when the package metadata is missing (PackageNotFoundError).
From a source checkout, uv sync installs the project itself, so the metadata exists → real version in the footer.
The Containerfile builder stage runs uv sync --frozen --no-dev --no-install-project (the app runs from /app/src via PYTHONPATH), so no yunjin dist-info exists anywhere in the image → the placeholder fallback fires.
CI passes --build-arg VERSION on release builds, but it only sets the OCI label org.opencontainers.image.version; the app never sees it.
Reproduced outside Docker: a scratch venv built with uv sync --frozen --no-dev --no-install-project + PYTHONPATH=src prints version: 0.0.0+unknown.

Plan of attack:

Make the builder stage install the project (drop --no-install-project, add the README.md + src/ build inputs) so the version metadata from pyproject.toml lands in the venv. importlib.metadata stays the single source of truth — no new env var, no drift risk.
Runtime stage unchanged: PYTHONPATH=/app/src still takes precedence over site-packages, so code keeps running from the source tree (the alembic.ini-relative init_db behaviour is preserved).
Update docs/container.md (describes the two-stage build) in the same change.
Add a smoke step to the CI container job: boot the built image, assert the footer shows the pyproject.toml version — the only automated check that can catch this at the layer where it broke.

Branch: feat/container-version-and-favicon (shared with the favicon issue).

**Findings** (root cause confirmed, not guessed): - `src/yunjin/__init__.py` resolves the version via `importlib.metadata.version("yunjin")` and falls back to `"0.0.0+unknown"` when the package metadata is missing (`PackageNotFoundError`). - From a source checkout, `uv sync` installs the project itself, so the metadata exists → real version in the footer. - The `Containerfile` builder stage runs `uv sync --frozen --no-dev --no-install-project` (the app runs from `/app/src` via `PYTHONPATH`), so no `yunjin` dist-info exists anywhere in the image → the placeholder fallback fires. - CI passes `--build-arg VERSION` on release builds, but it only sets the OCI label `org.opencontainers.image.version`; the app never sees it. - Reproduced outside Docker: a scratch venv built with `uv sync --frozen --no-dev --no-install-project` + `PYTHONPATH=src` prints `version: 0.0.0+unknown`. **Plan of attack**: - Make the builder stage install the project (drop `--no-install-project`, add the `README.md` + `src/` build inputs) so the version metadata from `pyproject.toml` lands in the venv. `importlib.metadata` stays the single source of truth — no new env var, no drift risk. - Runtime stage unchanged: `PYTHONPATH=/app/src` still takes precedence over site-packages, so code keeps running from the source tree (the alembic.ini-relative `init_db` behaviour is preserved). - Update `docs/container.md` (describes the two-stage build) in the same change. - Add a smoke step to the CI `container` job: boot the built image, assert the footer shows the `pyproject.toml` version — the only automated check that can catch this at the layer where it broke. Branch: `feat/container-version-and-favicon` (shared with the favicon issue).

agent-pi referenced this issue

2026-09-30 02:59:20 +00:00

Show the cloud as the app favicon #57

agent-pi referenced this issue from a commit

2026-09-30 03:04:45 +00:00

:bug: Ship package metadata in container image

agent-pi referenced this issue from a pull request that will close it,

2026-09-30 03:05:03 +00:00

Show real app version in container and add cloud favicon #58