Repository navigation
auto-version PEP440 stamp leaks into uv.lock via any plain 'uv run', breaking image metadata semver validation #695
Description
Chain: post-merge bot commit stamps flaskapi/pyproject.toml with X.Y.Z.devN (PEP440). uv.lock keeps the release form (develop convention), but the oSPARC image build validates the lock-derived project version as semver (MetadataConfig). Any tooling that runs plain uv run/uv sync (not --frozen) auto-mirrors the dev stamp into uv.lock -> verify-image-build fails with string_pattern_mismatch.
Hit live 2026-10-06 via PR #694 (ty hook auto-sync; hook fixed to --frozen in that PR's 16a95349). Remaining exposures: tests/e2e/scripts/gen-baselines.sh (make install-flaskapi-deps -> plain uv sync) and Makefile dev targets; harmless locally today only because their jobs don't inspect the lock afterwards.
Options (team call):
- derive image/oSPARC metadata version from a base-release source that the bot never stamps (VERSION file or
importlib.metadataof the locked release), decoupling display version from validation version; - or have the bot stamp both pyproject and a semver-safe metadata source atomically;
- or standardize
uv sync --frozen/uv run --frozenin all repo-invoked scripts and accept lock lag as an invariant (status quo hardened).
Related: #659 (auto-tag workflow), #682 (scripts/auto_version.py touch).
Activity
JavierGOrdonnez commentedon Oct 6, 2026
Concrete fix path for the metadata half of this trap is up as #697:
.bumpversion.cfgentries for the 8.osparc/*/metadata.ymlfiles get asemver-only = trueflag;auto_version.pystamps (and §V5 gate-checks) those entries with the.devN-stripped base while compose tags/pyproject keep the full dev version; the currently dev-stamped metadata files get a one-time repair. A dev stamp also self-heals metadata files the old flow left stamped.Evidence chain: #694's
verify-image-buildValidationError (input_value='1.6.3.dev2') →Assemble docker compose specvalidates.osparc/*/metadata.yml→ bumpversion fan-out writes the dev suffix there since195632ec→ every PR from stamped develop is affected, not just version bumps.Remaining exposure listed in this issue (plain
uv syncintests/e2e/scripts/gen-baselines.shre-stampinguv.lockduring §V12 runs) is untouched by #697 and still needs a call — reproduced again today on the #696 regen run (revision 3→5,1.6.3→1.6.3.dev2), caught and excluded before commit.fix(auto-version): route every bump through the semver-aware fanout (…
Merge pull request #697 from ITISFoundation/jgo/fix-stamp-semver
Merge pull request #697 from ITISFoundation/jgo/fix-stamp-semver
JavierGOrdonnez commentedon Oct 8, 2026
closed by #697