Improve CI persistence and MSRV testing, automate issue triage

[notmandatory]

Overview

Improve BDK Wallet CI processes for persistence and MSRV testing, and add automated issue triage.

Description

This is a tracking issue to improve our automated CI (continuous integration) testing and issue triage. For the CI improvements we need GitHub actions that run on every PR to confirm that no persisted data incompatibilities were introduced. We already have Github actions that confirm the codebase compiles both on the stable rust version and our chosen MSRV (minimum supported rust version), but these tests are brittle and hard to maintain. And finally for issue triage it would be nice to have a GitHub action that helps close stale issues so project contributors have an accurate list of issues to be worked on.

Expected Outcomes

The issues and sub-issues below should be completed.

• Downgrade Support #234
  • Add CI process to verify data created with the prior release version can be loaded with a new version
  • Add CI process to verify data created with new version can be loaded with the prior release version
• Improve MSRV testing
  • Investigate using cargo-rbmt for MSRV dep management #400
  • discussion: should we adopt the Cargo-minimal.lock and Cargo-recent.lock approach ? #79
• Automate stale issue triage #386
• Enforce signed commits
  • see: https://github.com/luisschwab/bdk-floresta/blob/master/.github/workflows/sigs.yml

Resources

• Github actions
• cargo-rbmt
• stale action

Skills Required

• hands on experience with git and GitHub
• basic rust programming skills
• basic sqlite DB skills
• be able to sign your git commits

Mentor(s)

@notmandatory

Difficulty

Medium

Competency Test (optional)

• Create a repo in your personal GitHub account
• Create and commit a simple rust "hello world" app with properly signed commits
• Add a simple Github Actions job to build and check the formatting of your app
• Add a feature branch to change your app in some way
• Create a PR from your feature branch

[graniteviper]

Hello, I would love to work on this issue. I've started reading through the existing BDK CI workflows and the linked issues (#234, #400, #386, #79 ) to understand the current setup.
I've completed the competency test — signed commits, a Rust hello world project, and a GitHub Actions CI workflow with build and fmt checks: https://github.com/graniteviper/ideal-octo-meme
I'd love any feedback on my competency test repo, and I'm happy to discuss my approach before diving into the actual work.

[luisschwab]

@notmandatory we could also add checking for signed commits on CI (see https://github.com/luisschwab/bdk-floresta/blob/master/.github/workflows/sigs.yml). This will further curb LLM-bot PRs, unless they figure out how to sign commits on their own.

[notmandatory]

https://github.com/luisschwab/bdk-floresta/blob/master/.github/workflows/sigs.yml

Good idea, added to the list.

[notmandatory]

@graniteviper thanks for taking at look at this. I'll start reviewing competency tests next week and proposals starting on April 20. See: https://www.summerofbitcoin.org/how-it-works/#timeline

[lambaaryan011]

Hello @notmandatory, I’m Aryan Lamba, a 3rd-year B.Tech Computer Science student, and I’m very interested in working on this issue for Summer of Bitcoin 2026.

I’ve completed the competency test with signed commits, a Rust hello-world project, and a GitHub Actions workflow (build + fmt):
https://github.com/lambaaryan011/bdk-competency-aryan

I’ve started going through the issue and related sub-issues (#234, #400, #386, #79) and had a few initial thoughts:

• For persistence testing, I’m thinking of setting up CI jobs that serialize wallet data using one version and validate deserialization across older/newer versions (bidirectional compatibility).
• For MSRV testing, I plan to explore making the workflow more stable and maintainable, possibly evaluating cargo-rbmt and lockfile strategies like Cargo-minimal.lock.
• For issue triage, I can integrate a stale bot workflow with configurable rules to keep the issue list clean without affecting active discussions.

I’d really appreciate any feedback on my competency repo and whether this direction aligns with your expectations.

Looking forward to contributing!

[KrishnaShuk]

Hi @notmandatory, I’m Krishna, a Summer of Bitcoin applicant. I’ve finished the competency test here: Competency-test.

I've been looking at the MSRV issues and studying how Luis used cargo-rbmt in the bdk-floresta PR (#82). I'm planning to use that same dual-lockfile approach here to replace the current pin-msrv.sh script.

For the persistence testing (#234), I’m figuring out how to handle the cross-version checks. Does the team prefer the CI to handle the git checkouts to generate/test the data, or should I use a different approach like stored artifacts?

Thanks.

[EliteCoder18]

Hi @notmandatory, I am Rishit, a Summer of Bitcoin applicant. I'm interested in working on the forward-compatibility piece of #234 (old data → new schema) as part of #410. I've done some local validation and wanted to share my findings before opening a PR

Background

I went through #300 and bitcoindevkit/bdk#2012 the test utilities are great for deterministic testing, but for cross-version checks we need data generated by an actual prior release.

What I tried

I validated a "checkout old release" approach locally using Git worktrees:

• wallet-2.0.0 — added a small dbgen.rs example to create and persist a SQLite wallet
• wallet-2.3.0 — added dbcheck.rs to load that DB

cd bdk_wallet-old && cargo run --example dbgen --features rusqlite -- /tmp/old.sqlite
cd bdk_wallet-latest && cargo run --example dbcheck --features rusqlite -- /tmp/old.sqlite

Result: the latest version successfully loads and re-persists the DB created by v2.0.0.

CI approaches I'm considering

1. Checkout & build previous release in CI — fully automated, but may hit toolchain / build issues on current runners.
2. Commit a fixture .db — simple, but requires manual updates when the schema changes.
3. Artifact pass between jobs — clean separation, but a more complex workflow to maintain.

I'm leaning toward (1) since it keeps everything automated and avoids drift.

Questions

• Has the checkout approach been tried before in BDK CI? Any known issues building older releases on current runners?
• If (1) turns out to be brittle, would committing a small fixture DB be acceptable as a fallback?

Happy to open a draft PR with a CI workflow based on this approach if the direction looks reasonable.

[graniteviper]

Hi @notmandatory, I explored integrating cargo-rbmt to simplify MSRV and dependency testing, especially leveraging its dual lockfile model (Cargo-minimal.lock and Cargo-recent.lock) for better version coverage.
However, while testing it against the current CI setup, I ran into a limitation.

The existing workflow consistently builds with: --no-default-features --features miniscript/no-std,bdk_chain/hashbrown

These features are required to make no_std builds compile successfully. Running with only --no-default-features fails due to dependency constraints (e.g., miniscript requires either std or no-std to be enabled).
The issue is that cargo-rbmt assumes feature independence and automatically tests combinations such as:

1. no features
2. individual features
3. random subsets

While exact_features can enforce specific combinations, it does not prevent cargo-rbmt from testing invalid ones, and does not scale well as feature sets grow.

Because of this, cargo-rbmt cannot be adopted out-of-the-box without either:

1. modifying its behavior, or
2. introducing workarounds that reduce maintainability

Would love to hear your thoughts on this. I’ve also explored a few alternative approaches for improving the CI pipeline and am happy to discuss those as well.

[notmandatory]

For above who requested to work on this please follow the summer of bitcoin application process so I can review everyone's proposals at the same time.