Skip to content

chore(release): update uv.lock to 0.10.0 - #423

Merged
eaitbrahim merged 1 commit into
mainfrom
chore/uv-lock-0.10.0
Aug 20, 2026
Merged

chore(release): update uv.lock to 0.10.0#423
eaitbrahim merged 1 commit into
mainfrom
chore/uv-lock-0.10.0

Conversation

@eaitbrahim

Copy link
Copy Markdown
Contributor

Fixes the failed 0.10.0 release run: https://github.com/CodeGateSoftware/keel/actions/runs/32316126013

What happened

#422 bumped the version in all seven pyproject.toml files and missed uv.lock, which is tracked and still pinned every workspace member at 0.9.3.

The workflow's "Sync dependencies" step regenerated it, which left the checkout dirty. "Stamp build info" then stamped a build from that dirty checkout, and keel --version reported:

warning: this build is NOT reproducible -- it does not correspond to a commit. Do not run it against live funds.
keel 0.10.0+29464f06ee11 (DIRTY) [release]
::error::artifact reports a dirty tree

The guard did exactly its job. version.build_info() re-checks git status --porcelain against the stamp rather than trusting it — the "believe git over a stale stamp" branch — and a (DIRTY) build corresponds to no commit, which RELEASING.md says must never run against live funds. Lint, Type-check, Test and Build all passed; nothing was tagged and nothing was published.

The fix

uv lock. Seven lines, one per workspace member:

Updated keel-broker-alpaca    v0.9.3 -> v0.10.0
Updated keel-broker-api       v0.9.3 -> v0.10.0
Updated keel-broker-coinbase  v0.9.3 -> v0.10.0
Updated keel-broker-fake      v0.9.3 -> v0.10.0
Updated keel-broker-robinhood v0.9.3 -> v0.10.0
Updated keel-core             v0.9.3 -> v0.10.0
Updated keel-trader           v0.9.3 -> v0.10.0

No third-party dependency resolution moved — the diff is 7 insertions, 7 deletions.

Verified by reproducing the CI condition

With the lock committed, uv sync now leaves the working tree clean. That is the precise condition that failed: the release stamps from a checkout that has just been synced, so uv sync leaving anything modified is what makes the artifact unreleasable.

Follow-up worth considering

The lockfile is only checked implicitly, by the dirty-tree guard three steps later, and the error it produces ("artifact reports a dirty tree") does not name the cause. A uv lock --check immediately after checkout would fail in seconds with "the lockfile is out of date" instead of failing after Build with a message that sends you looking at the stamp. Happy to open that as a separate PR.

🤖 Generated with Claude Code

#422 bumped the version in all seven `pyproject.toml` files and missed
`uv.lock`, which is tracked and still pinned every workspace member at
0.9.3. The release workflow's "Sync dependencies" step then regenerated it,
which left the checkout DIRTY, and the build stamped from that checkout
identified itself as

    keel 0.10.0+29464f06ee11 (DIRTY) [release]

so "Verify the artifact identifies itself" refused to go on. That guard did
exactly its job: a `(DIRTY)` build corresponds to no commit, and
`docs/RELEASING.md` is explicit that such a build must never run against
live funds. Nothing was tagged and nothing was published.

Regenerated with `uv lock`, which touches only the seven workspace members'
versions -- no dependency resolution moved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@eaitbrahim
eaitbrahim merged commit 24aa56f into main Aug 20, 2026
4 checks passed
@eaitbrahim
eaitbrahim deleted the chore/uv-lock-0.10.0 branch August 20, 2026 00:12
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