fix(ci): keep uv.lock self-version entry in lockstep with pyproject.toml#4
Merged
Merged
Conversation
release-please's first release PR (#2) failed CI because pyproject.toml got bumped to 0.1.1 while uv.lock's `cfn-lint-cfn-handler` self-version entry stayed at 0.1.0. Our CI uses `uv sync --locked`, which rejects the drift. Same root cause + same fix as cfn-handler. The `extra-files` block tells release-please to update uv.lock alongside pyproject.toml on every bump. The `.value` in the jsonpath is essential — release-please's GenericToml updater navigates an internal AST where string nodes are `{value, kind}` objects, not bare strings. The bare form `name == 'cfn-lint-cfn-handler'` does NOT match (see googleapis/release-please#2455 for upstream context). Once this lands on main, release-please will re-update PR #2's branch with the matching uv.lock bump and CI on that PR will go green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Release PR #2 fails CI because release-please bumped
pyproject.toml0.1.0 → 0.1.1 but
uv.lock'scfn-lint-cfn-handlerself-version entrystayed at 0.1.0. Our CI runs
uv sync --locked, which rejects the drift.The bootstrap doc §5 specifically warned about this and prescribed the
extra-filesblock, which I missed in the bootstrap PR. Same root cause +same fix as the sibling
cfn-handler.What
Add
extra-filestorelease-please-config.jsonso release-pleaseupdates the matching uv.lock entry on every version bump.
The
.valuein the jsonpath is essential — release-please'sGenericTomlupdater walks an internal AST where string nodes are{value, kind}objects, not bare strings. The barename == 'cfn-lint-cfn-handler'does not match. Seegoogleapis/release-please#2455
for upstream context; PR #2693
proposes to make the bare form work, but until it lands the
.valueworkaround is what we have.
What happens after merge
Release-please re-runs on the merge to main, recomputes PR #2's
branch with the matching uv.lock bump, force-pushes the branch, CI
re-runs on PR #2, goes green. Then PR #2 is mergeable and ships
v0.1.1 to PyPI.
Follow-up
Bootstrap doc §9 told us to skip cfn-handler's
tests/release-please/local validator for v0.1.0 (YAGNI). This bug is exactly the kind that
validator catches. Worth porting over before the next release adds
non-trivial release-please complexity.