Commit Cargo.lock

[newpavlov]

This should improve CI times a bit since it allows cargo to skip update of the crates.io index.

The main disadvantage is that we will need to manually update it from time to time and that we may not immediately notice bugs in upstream dependencies.

[josephlr]

It seems really useful to immediately notice bugs in upstream dependencies, but the deterministic builds/tests is quite nice.

Would it be possible to have some automation which bumps the Cargo.lock when a new transitive dependency gets released? I probably wouldn't want to rely on us having to manually update the file every now and then.

This could also help us with minimal version stuff, where we could have a Cargo_minimal.lock which we use to make sure our crate works with our specified minimum versions. But that's probably best left for another time.

[josephlr]

@newpavlov do you know if there's a way to have Cargo.lock included as part of what the Swatinem/rust-cache action handles? Then we could cache a previous build's lockfile and then only need to pull stuff from crates.io when there's an updated dependency.

[newpavlov]

Would it be possible to have some automation which bumps the Cargo.lock when a new transitive dependency gets released?

We probably could create a Cron CI job for this. Though I never tried something like this. There is also a small concern about potential MSRV breakeage caused by the upstream dependencies, so it would be nice to be able to use the MSRV-aware resolver for this.

do you know if there's a way to have Cargo.lock included as part of what the Swatinem/rust-cache action handles?

In most my other repositories I just commit Cargo.lock, so I never tried it.

[tamird]

An alternative to this is to run CI every day. That will update your cache and ensure that PR builds are fast. We do this in aya.

[newpavlov]

I added the weekly job to update Cargo.lock. I am not sure that I configured everything properly, so I downgraded libc to one patch version to see whether the job works as expected.

[tamird]

Why not just run normal CI every day to hydrate the cache? Checking Cargo.lock in is generally not advised for libraries. Won't it prevent downstream crates from using a newer libc patch version, for instance?

[newpavlov]

No, it will have no effect on downstream libraries. As for "not advised", it's a debatable point. For example, in RustCrypto we commit lock files to all our repositories and it works fine for us.

[newpavlov]

Relevant blog post: https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

[tamird]

Ah, indeed. However, it will prevent your CI from testing newer versions of libc, which downstream might use.

https://doc.rust-lang.org/cargo/faq.html?highlight=cargo.lock#why-have-cargolock-in-version-control