Better CI hygiene follow-up

[tomtau]

My current understanding of best practice is different from what we're currently doing here, though. Probably in a follow-up, it would be better practice to have

• check
  • +pin-nightly generate-lockfile -Zminimal-versions
  • +pin bootstrap --locked
  • +msrv check --locked
• lint
  • +pin-nightly generate-lockfile -Zminimal-versions
  • +pin bootstrap --locked
  • +pin clippy --locked -Dwarnings
  • +pin fmt --check
• test
  • +pin-nightly generate-lockfile -Zminimal-versions
  • +pin bootstrap --locked
  • +pin-stable test --locked
• future (allow-fail)
  • +beta generate-lockfile
  • +beta bootstrap --locked
  • +beta test --locked

The goal is to avoid anything changing between CI runs except the local code.

Originally posted by @CAD97 in #654 (comment)

[CAD97]

An additional challenge mode: we'd prefer if we can generate code which is warning free on all versions MSRV+, and it'd also be nice to test that the project compiles on all versions in the supported range.

cargo-hack may be of interest. For practicality reasons, I'd suggest checking a rolling stable-3 or stable-6 with hack rather than all the way down to MSRV.

But also this is probably way overengineered of a CI pipeline for what we actually need for the project (which is to be aware of MSRV bumps and run tests/lints/fmt on a recent ish toolchain)

[tomtau]

@CAD97 any good references for CI pipelines?
tokio is using cargo hack for testing features: https://github.com/tokio-rs/tokio/blob/master/.github/workflows/ci.yml#L94 but they don't test the version ranges.

[CAD97]

Tracing does check the version range; I have a separate repo component with a workflow derived from tracing's workflow; it's --version-range to test a range of versions.

If we're updating the CI pipeline, it's probably best to move off of actions-rs (unmaintained) and to either just using run: rustup or dtolnay/rust-toolchain instead.

[tomtau]

One more thing to add is to test no_std support: #409 (comment)

• https://github.com/hobofan/cargo-nono
• https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
• or this: rustup run nightly -- cargo build -j1 -Z build-std=core,alloc --target x86_64-unknown-linux-gnu should fail to compile if any dependency uses std