Skip to content

chore: relock at 0.4.0 so the release build is not dirty - #166

Merged
eaitbrahim merged 1 commit into
mainfrom
fix/lock-0.4.0
Aug 5, 2026
Merged

chore: relock at 0.4.0 so the release build is not dirty#166
eaitbrahim merged 1 commit into
mainfrom
fix/lock-0.4.0

Conversation

@eaitbrahim

Copy link
Copy Markdown
Contributor

Fixes the failed 0.4.0 release (run 31032617294).

What failed

keel 0.4.0+eae6c0437fdd (DIRTY) [release]
::error::artifact reports a dirty tree

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.lock pinning 0.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 runs keel --version inside the checkout, git status --porcelain is non-empty.

version.build_info() deliberately consults git even when a stamp is present:

⚠️ A STALE stamp in a working checkout would otherwise claim [release] and hide a dirty tree — which is precisely the misreport this module exists to prevent. If git is present and disagrees with the stamp, believe git.

So this was the guard working correctly. The stamp said DIRTY = False honestly; the tree genuinely was dirty. Worth noting keel/_build_info.py and dist/ 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 on main produced exactly M uv.lock, and it moves all five members 0.3.2 → 0.4.0. No 0.3.2 remains in the lock.

No tag was created (the workflow tags after verification), so re-running Release with 0.4.0 after this merges is clean — no tag to delete.

1698 tests pass.

🤖 Generated with Claude Code

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>
@eaitbrahim
eaitbrahim merged commit dc99601 into main Aug 5, 2026
1 check passed
@eaitbrahim
eaitbrahim deleted the fix/lock-0.4.0 branch August 5, 2026 18:46
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