We've decided to try using some of our funding to speed up CI.
kbknapp has experience with buildjet in the past which allows us to keep
our Actions and switch out our runners.
As we are charged for `num_cores * time`, increasing core counts could
decrease time, both helping us and keeping costs down.
I chose 8 cores (an upgrade over `ubuntu-latest`s 2 cores) as kbknapp
knew someone who benchmarked things for Rust/Python and found that a
good fit.
I only switched a subset of jobs over to buildjet to focus on jobs where
most of the time is spent on highly parallelizable operations.
Buildjet dropped our Linux test jobs from 8-9min to 2-3min.
The checks and UI-test jobs only improved by 30s-1min each, so I left
them out.
We can iterate as we go.
`-h` (short help) still shows the same.
This gates it behind an `unstable-v4` feature flag to avoid disrupting users who set the help without knowing where all it shows up (particularly derive users where `ArgEnum` is automatically extracting the help).
Fixes#3312
I was working to drop the active features across all crates, so that
when cargo unified them during `--workspace`, we'd get this for free.
Alas, it looks like its not happening.
This drops us down to just a handlful of jobs, allowing us full
parallelism (github caps max parallel jobs). This is dependent on us
using bors to run the "ci" before merging into master.
There is a balance in what to run. We should consider what is most
likely to break for the widest variety of PRs. Contributors that expect
an uncovered case to fail can always specify `@bors try`
Motivation
- Mac is similar enough to Linux, we only need to run one of them and
Linux has more parallel runners on Github.
- Since we deal with `OsStr`, test Windows because its different than
the others.
- People are most likely to make changes on `stable` and break support
for MSRV, so we should verify that
- Still test on `stable` to not block feedback if we run into problems
with dependencies and our MSRV run.
- On the other hand, beta and nightly are less likely to break on an
individual PR
- Remove benchmarks because most changes are not performance sensitive
and we aren't looking at the results enough to justify a 30 minute run.
Fixes#2801
Using `head_ref`, we are making it so PRs are all in the same group.
When a new PR comes in (not just an update), it then cancels all other
PRs. Switching to `ref` makes it so each PR is in its own concurrency
group.
