Refactor CI msrv & minver checks

[CAD97]

Motivation

Test msrv and minimal-versions compliance in the currently best-known fashion.

Solution

• Use cargo-hack and cargo-minimal-versions
• Also I replaced uses of actions-rs (abandoned) while I was passing by

[hawkw]

one question about this change, just to make sure I understand the motivation here.

as a side note, i'm not super excited about how all these files were re-formatted, i'm now concerned that any subsequent modifications i make will reformat them differently...perhaps we ought to check in an .editorconfig for yaml files or something, to ensure different people's editors don't reformat them as often. but, it's not a huge deal.

[hawkw]

what happened to the minimal-versions job? it seems to have disappeared --- is this because we think the +MSRV -Zminimal-versions run is sufficient to ensure minver compatibility? do we no longer need to check it on stable as well?

[CAD97]

Yes, the theory is that checking +MSRV -Zminimal-versions is sufficient, and that standard backwards-compatibility guarantees imply that +stable -Zminimal-versions will also work. This isn't guaranteed, but we can have fair confidence since we're testing stable with normal maximal version resolution.

[CAD97]

Unfortunately the change here I think cannot be covered in an editorconfig; it's changing

# from
---
key:
- list
- of
- values

# to
---
key:
  - list
  - of
  - values

and short of switching to flow syntax everywhere, there doesn't seem to be a standard¹ "use this option" config file. Interestingly, in a quick search, nearly every example uses the second form except for the official YAML spec.

Either way, we probably should normalize to one option or the other; most of our YAML is using shallow lists but not all. I went ahead and cleared that change out in a rebase to avoid making that call here.

Footnotes

1. We could add a vscode workspace configuration for @ext:redhat.vscode-yaml to disable the formatter, which would cover the 90% case probably. I checked; it doesn't appear to have a setting for "shallow" list indentation. ↩

[CAD97]

What this doesn't check is that --no-default-features also checks on +MSRV minimal-versions... doing a full --feature-powerset¹ is probably overkill but it seems valuable to at least check without optional dependencies to remove their version constraints on the kept dependencies.

[ci run I'm looking at]

That would necessitate another CI matrix split like in the existing feature powerset job. Given the cargo-msrv job is nearly as long as a build and can't really benefit from a cache the way the actual builds can, perhaps this would be a good idea anyway... the longest single-crate feature powerset check is a minute, whereas this job is nearly three. Caching got the tests down to under four minutes on linux.

Footnotes

1. Is just powersetting optional-deps and not other features a) possible in cargo-hack and b) sufficient? ↩

[hawkw]

Okay, the YAML change isn't really a big deal, and I'm fine with whatever style we end up using as long as my vscode install doesn't automatically reformat everything as soon as I open a config. :)

[CAD97]

I added the matrix jobs, it's your call whether to keep them or not.

previous ci ran in 12:30; this ci ran in 14:00. A cursory overview suggests that each matrix job has about 20s of overhead compared to running that check in a shared job.

(As far as CI time optimization goes, though, the big win would be caching dependency compilation on the test runners.)

[hawkw]

I added the matrix jobs, it's your call whether to keep them or not.

previous ci ran in 12:30; this ci ran in 14:00. A cursory overview suggests that each matrix job has about 20s of overhead compared to running that check in a shared job.

(As far as CI time optimization goes, though, the big win would be caching dependency compilation on the test runners.)

Hmm, the extra 1:30 or so of runtime is kind of a bummer, but I'm going to move forward with this change regardless, since it cleans up a bunch of stuff that I'd like to get fixed up. Let's try adding caching in a subsequent branch maybe?

[CAD97]

Sounds good to me.