chore: relock at 0.4.0 so the release build is not dirty - #166
Merged
Conversation
The 0.4.0 release failed at "Verify the artifact identifies itself":
keel 0.4.0+eae6c0437fdd (DIRTY) [release]
::error::artifact reports a dirty tree
The version bump (#165) moved all five workspace members to 0.4.0 but left
uv.lock pinning 0.3.2. CI's `uv sync` step then relocks to match, which
modifies a TRACKED file, so by the time the verify step runs
`keel --version` inside the checkout the tree is dirty.
That is the anti-stale-stamp guard in version.build_info doing its job: a
stamp is only believed when git agrees with it, precisely so a stamped build
of a modified tree cannot claim to be a clean release. The stamp was honest;
the tree really was dirty.
`keel/_build_info.py` and `dist/` are both gitignored, so neither the stamp
nor the build output is what tripped it -- only the lock was.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Fixes the failed 0.4.0 release (run 31032617294).
What failed
Lint, tests, stamp and build all passed. Only the self-identification check failed.
Why
#165 bumped all five workspace members to 0.4.0 but left
uv.lockpinning0.3.2— my miss. CI's Sync dependencies step relocks to match, which modifies a tracked file. By the time Verify the artifact identifies itself runskeel --versioninside the checkout,git status --porcelainis non-empty.version.build_info()deliberately consults git even when a stamp is present:So this was the guard working correctly. The stamp said
DIRTY = Falsehonestly; the tree genuinely was dirty. Worth notingkeel/_build_info.pyanddist/are both gitignored, so neither the stamp nor the build output can trip this — the lock was the only tracked file involved.Fix
uv lock, committed. Reproduced locally first: running it onmainproduced exactlyM uv.lock, and it moves all five members 0.3.2 → 0.4.0. No0.3.2remains in the lock.No tag was created (the workflow tags after verification), so re-running Release with
0.4.0after this merges is clean — no tag to delete.1698 tests pass.
🤖 Generated with Claude Code