search

dalek-cryptography / curve25519-dalek

A pure-Rust implementation of group operations on Ristretto and Curve25519
Other
853 stars 422 forks source link

CI: fix minimal-versions resolution #593

Closed tarcieri closed 8 months ago

tarcieri commented 8 months ago

To avoid nightly regressions breaking the build, the CI configuration has been updated to only use nightly for resolving Cargo.lock by using cargo update -Z minimal-versions.

Previously, it was running cargo check which would attempt to compile all of the dependencies and the code, which is why the diagnostic bug was triggered. By avoiding any kind of code compilation using nightly we can avoid such regressions in the future.

Additionally, the clippy job has been changed to run on the latest stable release (1.73.0) rather than nightly, which will prevent future clippy lints from breaking the build. Instead, they can be addressed when clippy is updated.

rozbb commented 8 months ago

Unused import stuff is fixed in https://github.com/dalek-cryptography/curve25519-dalek/pull/590

tarcieri commented 8 months ago

It is? How?

Regardless, this approach should be more futureproof in regard to any other nightly regressions.

rozbb commented 8 months ago

Some of the contents of field.rs was pub use, but the module itself is only pub(crate). I suppose the new warning could be a bug, but it still points out correctly that there was a lot of superfluous pub use.

I agree about the CI being more robust. My only concern is that this adds another chore (updating pinned nightly). Is there a buildabot type automation for this?

tarcieri commented 8 months ago

@rozbb if you merge #590 I can unpin nightly

rozbb commented 8 months ago

Merged

tarcieri commented 8 months ago

Updated with the nightly pin removed, although notably if we don't pin nightly it's a source of nondeterminism in the build.

I still think the other changes simplify/stabilize the build if we don't do that, but personally I find it frustrating whenever the build breaks due to things unrelated to my changes.

rozbb commented 8 months ago

I agree. If we had a more streamlined way of addressing it separately from our PRs then I'd go for it. Only reason I think we should have nightly in the CI is bc it forces us to make changes for what's coming down the pike into stable.

If you still think it's more reasonable to pin, though, then I'm happy to do it

tarcieri commented 8 months ago

Let's cross that bridge when we get there (again), I guess.

At least these changes will limit the scope of the failures to the nightly test.