You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MSRV requires provided lockfile, CI should test more versions of dependency crates #940
We provide two Cargo.lock files, Cargo-{minimal,recent}.lock, but they are (have been?) always the same.
Many of our Cargo.toml version specifications are not semver based (x, or x.y) but exact (x.y.z).
For each toolchain version the ./contrib.test.sh script tests using both lockfiles, which just reruns the tests with the same dependency versions. This means that recently and currently having two lockfiles is just delaying test results.
For better compatibility testing it would be more useful if our version constraints relaxed so that the lockfiles diverged. MSRV would only with the minimal one, whereas more recent toolchains were tested against deps that require more recent versions of rust. See also #774
Secondly, we should cargo test also without using any of the provided lockfiles. Different lockfiles will be produced from what is provided.
MSRV & stable fail without a provided lockfile using cargo from the toolchain (base64ct is an indirect dev dep resulting from the bitcoind crate's dependency on the zip crate):
error: failed to download `base64ct v1.8.0`
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at `/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/base64ct-1.8.0/Cargo.toml`
Caused by:
failed to parse the `edition` key
Caused by:
this version of Cargo is older than the `2024` edition, and only supports `2015`, `2018`, and `2021` editions.
Third, we should also consider testing against new versions of crates that fit our version constraints, in a scheduled job (maybe once a week?). This would alert us of
potential breakage due to imprecise semver specifications.
Activity
benalleng commentedon Jun 16, 2026
I don't think this is appropriate for CI as it would cause failures that are not important for unrelated PRs. perhaps this could be an addition to the new weekly cargo.lock cron job. But that already uses a fresh build via this script https://github.com/payjoin/rust-payjoin/blob/master/contrib/update-lock-files.sh
Closed by #1640