Skip to content

Pin the uv release toolchain and commit the lock in its marker normalization - #9444

Merged
MaxGhenis merged 1 commit into
mainfrom
max/release-lock-uv-toolchain-20260911
Sep 12, 2026
Merged

MaxGhenis merged 1 commit into
mainfrom
max/release-lock-uv-toolchain-20260911

Conversation

@MaxGhenis

Copy link
Copy Markdown
Contributor

Why

The first automatic version bump after #9428 (push run 34657438359) failed in Update versioning at python .github/release_lock.py --refresh:

Updated policyengine-us v1.825.2 -> v2.0.0
release_lock.py: error: Versioning changed the reviewed dependency graph; prepare and review a registry lock first

The runner installs the latest uv (0.12.13; setup-uv found no pin and fell back to latest) while the committed lock was written by uv 0.11.7. A fresh lock is left alone by either version (--committed passed on the same runner minutes earlier), but the bump forces a re-resolution, and 0.12.13 then rewrites 37 resolution-marker lines in its own normalization (for example python_full_version < '3.12' markers on the sphinx tree). The guard compares the whole graph minus the root version and refuses, as designed. Reproduced locally: uv 0.12.13 at version 2.0.0 rewrites 38 lines; uv 0.11.7 rewrites the root version alone.

What

  • uv.lock: regenerated by uv 0.12.13 after a forced re-resolution (bump the root version, lock, restore it, lock). 37 marker lines change; no package, version, hash or source changes. Root version stays 1.825.2.
  • Workflows: version: "0.12.13" on all 22 astral-sh/setup-uv steps in push.yaml, pr.yaml, weekly-uv-lock.yaml, so the uv that checks and refreshes the lock is the one that wrote it.
  • .github/release-lock.md: how to move the pin (change it in all three workflows and regenerate the lock the same way in one reviewed PR).
  • Changelog fragment.

Verification

  • With this lock, bumping to 2.0.0 and running the guard's exact uv lock command under uv 0.12.13 leaves the graph identical except the root version, by release_lock.without_root_version comparison (the guard would pass).
  • uv lock --check under uv 0.11.7 and 0.12.13 both pass on this lock and leave it unchanged.
  • .github/tests/test_release_lock.py: all pass.
  • All three workflow files parse.

Merging this re-triggers the push workflow on main; its versioning job should now bump to 2.0.0 and publish.

🤖 Generated with Claude Code

…ization

The first automatic version bump after #9428 failed closed in the release
lock guard: "Versioning changed the reviewed dependency graph". The runner
installs the latest uv (0.12.13, unpinned) while the committed lock was
written by 0.11.7. A fresh lock is left alone by either version, but the bump
forces a re-resolution, and 0.12.13 then rewrites 37 resolution-marker lines
in its own normalization; the guard compares the whole graph and refuses.
Reproduced locally with uv 0.12.13 at version 2.0.0; under 0.11.7 the same
refresh changes only the root version.

Commit the lock as 0.12.13 writes it after a re-resolution (bump, lock,
restore, lock: 37 marker lines change, no package or version changes), and
pin uv 0.12.13 in every setup-uv step of the push, pull request and weekly
lock workflows so the toolchain that checks the lock is the one that wrote
it. With this lock the 2.0.0 refresh differs from the committed graph in the
root version alone, by the guard's own comparison. uv 0.11.7 still passes
`uv lock --check` on it, so developers need no upgrade. The release-lock
document records how to move the pin.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@MaxGhenis
MaxGhenis merged commit 21b4ba6 into main Sep 12, 2026
33 checks passed
@MaxGhenis
MaxGhenis deleted the max/release-lock-uv-toolchain-20260911 branch September 12, 2026 00:27
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