Skip to content

fix: pin zingolib by rev, unbreaking CI after the branch deletion - #1212

Open
zancas wants to merge 2 commits into
devfrom
fix_zingolib_pin
Open

fix: pin zingolib by rev, unbreaking CI after the branch deletion#1212
zancas wants to merge 2 commits into
devfrom
fix_zingolib_pin

Conversation

@zancas

@zancas zancas commented Jul 26, 2026

Copy link
Copy Markdown
Member

Unbreaks every dev-based CI run. Upstream merged feat/ironwood into zingolib dev (zingolib#2419, 2026-07-24 04:59 UTC) and deleted the branch, so the "Resolve zingolib rev" step's git ls-remote resolves nothing and fail-all cancels the run. Both nightlies and every PR against dev have been red from this single cause since; the last good resolve was 2026-07-23 21:23 UTC.

This pins zingolib, pepper-sync, and zingolib_testutils to b09ebf53, the deleted branch's final tip. The first commit pinned the lockfile's frozen ba5fdef4; running CI on it exposed the second, older failure: the lock had silently lagged the branch, and the eleven commits it was missing include the pool-activation derivation fix (zingolib ADR 0014), without which regtest wallets never treat Ironwood as active and the calibrated integration ledger fails (issue #1213, ironwood 0 / orchard 710000). Moving the pin forward to zingolib dev is a deliberate follow-up with its own review, not part of this unbreak.

Related: #1211 hardens the image pull that a separate runner egress flake killed; it is blocked on red checks that this PR unbreaks.

🤖 Generated with Claude Code

Upstream merged feat/ironwood into zingolib dev (zingolib#2419,
2026-07-24) and deleted the branch. Every CI run based on this repo's
dev has failed since at the "Resolve zingolib rev" step, because the
manifest pinned zingolib, pepper-sync, and zingolib_testutils by that
branch name and git ls-remote now resolves nothing. Both nightlies and
every PR against dev are red from this single cause.

Pin all three dependencies to ba5fdef4, the exact commit Cargo.lock was
already frozen at, so the compiled dependency tree is unchanged and the
ci-build image for this source state is known to exist. Moving the pin
forward to zingolib dev is a deliberate follow-up with its own review,
not part of this unbreak. The Cargo.lock delta is the source-string
format only; the resolved commit is identical.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The previous commit pinned ba5fdef4, the commit Cargo.lock had frozen.
Running CI on it exposed why dev was already failing before the branch
deletion: the eleven commits between ba5fdef4 and the branch tip
include the pool-activation derivation fix (zingolib ADR 0014), and
without it a regtest wallet never treats Ironwood as active. Shield and
self-send change land in Orchard, and ExecuteSaplingBalanceFromSeed
reads ironwood 0 / orchard 710000 against the calibrated ledger of
ironwood 430000 / orchard 260000 (issue #1213). The lockfile had
silently lagged the manifest's branch.

Pin all three zingolib-repo dependencies to b09ebf53, the branch's
final tip, which carries the derivation fix and matches the ledger the
integration tests assert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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