Skip to content

MSRV requires provided lockfile, CI should test more versions of dependency crates #940

Closed

Description

@nothingmuch

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.

Whereas nightly produces a different lockfile:

$ sha256sum Cargo*.lock
91af669665c87ed8b1d62182df8de837b7305ec7193678b763e69c447c542c72  Cargo-minimal.lock
ced176873f39b270ce00e0eeb4826e302a299f3222e22fb1da89bf944970d991  Cargo-nightly.lock
91af669665c87ed8b1d62182df8de837b7305ec7193678b763e69c447c542c72  Cargo-recent.lock

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

  1. benalleng commented on Jun 16, 2026

    @benalleng
    Collaborator

    Secondly, we should cargo test also without using any of the provided lockfiles. Different lockfiles will be produced from what is provided.

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions