Use fixed version of Rust toolchain for releases

[patriknw]

Reproducible builds of releases are important.

[huntc]

I’m unsure that this is required. Toolchain and compiler releases are backwards compatible and so releases should always be able to be rebuilt. You’d also have to persist the cargo lock file, which is generally not done for libs.

We already have a min Rust version enforced to help out here.

[huntc]

Actually, it appears that the advice of storing the lock file changed late last year (again?).

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

This wouldn’t have prevented the toolchain being updated though. Clippy would still have complained, although you can ignore its warnings if needed.

[huntc]

I also just checked tokio, Axum and hyper, and none of them check in the lock file either. Pros and cons.

[huntc]

An additional consideration... when a binary is checked in that depends on various libraries, it does tend to include its lock file thereby achieving reproducible builds. I've also found myself pinning the toolchain on occasion, but this is less necessary. And, if needed, pinning can be retrospectively applied. In fact, the only time I've needed to pin the toolchain was when the compiler moved the MIPS32 target from being supported as a Tier 2, and so I needed an older one. Toolchains can be pinned using a rust-toolchain.toml file at the same level as Cargo.toml.