There's a good CI time reduction from this due to lowering the number of jobs from 39 to 31. The latest CI run succeeded in 5:30. Previous runs were 8-15 mins.

Bencher Report

⚠️ WARNING: The following Measure does not have a Threshold. Without a Threshold, no Alerts will ever be generated!

• Latency

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds CLI flag.

Does doing this have any workspace-related advantages other than speeding up the CI? I haven't worked with xtask before so I'm trying to understand the benefits. I'd be happy if you can provide more information (maybe in the commit summary) why this is better than cargo-make.

Does doing this have any workspace-related advantages other than speeding up the CI? I haven't worked with xtask before so I'm trying to understand the benefits. I'd be happy if you can provide more information (maybe in the commit summary) why this is better than cargo-make.

Regularly when I run cargo make, it tells me there's an update available. That was the bit that annoyed me enough to do this.
I've been thinking about this for some time, and the rationale is mentioned in the link:

• It doesn't require any other binaries besides cargo and rustc, it fully bootstraps from them
• Unlike bash, it can more easily be cross platform, as it doesn't use the shell.

By using an xtask approach, all the CI steps that previously needed cargo-make already have the necessary tools they need to run installed (and these are likely cached between runs too).

My secondary rationale is a general distaste for implementing imperative logic (here instructions on what and how to build) in declarative languages (here toml) or in shell scripts. The code for detecting the default workspace members to run the cargo-docs-rs packages would have been difficult to get right, and would have tended to just be hardcoded instead of letting the existing workspace metadata define what is built. I just like looking at rust for this. It looks pretty simple and obvious.

I also wanted something that would be easy to extend into watching for changes and checking that things are ready for PR in the background (to save having to make small clippy / typos / formatting issue updates), and which could our existing shell scripts (for releases and vhs generation)

Lastly I wanted to experiment with the approach, as it seems like a neat idea generally.

I don't think much of this really belongs in the changelog, which IMO should really contain info about user focused things and less internal things like this.

Fair enough.