Investigate ways to make CI faster

[matthiasbeyer]

I really don't like how slow CI is for this repository.

If someone wants to make CI faster, I'd love to see PRs for that!

[polarathene]

Just came across this, might be worth looking into if someone does tackle this:

• https://nexte.st/
• https://github.com/nextest-rs/nextest

Doesn't really look like the tests are using that much time, more so on the build portion prior.

---

You could have your matrix build jobs start with building config-rs with dev-dependencies, and uploading that artifact for all subsequent matrix jobs to download a copy of. Might be a speed-up.

If actions/cache action can be leveraged, that's usually nicer and they can avoid that initial job, one will upload the cache if it's fresh and subsequent runs of the CI will bring in that cache if nothing has changed (eg: Cargo.lock).

---

I haven't worked with Rust with Github Actions, but I imagine you could cache some of the time consuming parts. I see in the actions history:

• Some jobs take 5 minutes to run cargo --check. Those seem to be for a specific MSRV version rather than stable/beta/nightly channels. Not sure why they are slower, perhaps Github has some cache proxy layer for the more common channels to save bandwidth? 🤷‍♂️
• Other jobs like cargo clippy and cargo test can take 1-2 minutes to download and compile the crates, which is the bulk of the jobs. Leveraging cache would help there a fair bit.

A quick look, this action seems to be a popular way to cache dependencies, benefits from a Cargo.lock being present, with only caveat being less useful on Nightly toolchain. So that should hopefully make a difference with #492 👍