run tests in CI

[danieleades]

• refactors the CI workflow to group targets by action (check or test) rather than by toolchain
• converts the 'check' targets into a unified matrix target
• adds a 'test' target to run the tests in CI
• runs the checks in parallel instead of in sequence
• adds an '--all-targets' check on stable to check the bench and test targets

outstanding questions-

• are all of these matrix targets needed, or can this be trimmed down further?

I believe merging this will unblock adding configuration to allow dependabot to bump rust deps in this repo, since the CI will catch breaking changes in dev dependencies with these changes. see #674

[jswrenn]

bors r+

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• bors build finished

[Philippe-Cholet]

Coming from #720, I'm surprised to see we test againt rust 1.62.1 and not rust 1.36.0. I do not see a discussion about this change.
Does that mean the MSRV is updated? Then update the module doc of "lib.rs" and rust-version in Cargo.toml?
I guess we were gonna update that soon anyway.

[jswrenn]

I noticed that too while reviewing. It's unfortunate that happened. My guess is that a dev-dependency has a higher MSRV. I'll reorganize our CI again soon and address this.

[danieleades]

I noticed that too while reviewing. It's unfortunate that happened. My guess is that a dev-dependency has a higher MSRV. I'll reorganize our CI again soon and address this.

having a look at this now. Your guess is correct- it's Criterion that's pushing up the MSRV.
You'd need a way to exclude the dev dependencies when running cargo check, as they are built and checked by cargo by default (even if running cargo check --lib)

Looks like cargo hack might provide a way forward?

[Philippe-Cholet]

Alternatively, maybe we could just decrease criterion version as needed for a little while? I don't see any recent changes in "benches" that would rely on a newer version.
In the recent #702, it was briefly discussed to increase the MSRV (implicitely soon enough). We could then just increase versions back?

[danieleades]

Alternatively, maybe we could just decrease criterion version as needed for a little while? I don't see any recent changes in "benches" that would rely on a newer version.

that's a temporary fix, but you'll still have the general problem that downstream users are unnecessarily restricted to the MSRV of the dev dependencies used by the this crate. A solution that decouples downstream users from developers would be preferable

[danieleades]

see #754