feat(xtask): 'changes' xtask

[epage]

This will report what commits affect each publishable package and serves as an alternative to #12085.

CI can run this as cargo changes HEAD~ HEAD^2 and that will capture all of the commits within the PR (this is the range I used in committed).

There is still work needed to integrate this with an action; this is just a rough base-line implementation.

I originally tried to use cargo package --list to determine what files belong to what packages but that was taking too long for some reason (it works well in cargo release for my crates). We can either look into that in the future or do our own heuristics to filter out content.

[rustbot]

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

[weihanglo]

Thanks for the fast prototyping. This looks pretty complete to me!

Some thoughts:

• The cargo project doesn't adopt git conventional commit message pattern. Not sure if it is worthy or we should enforce that.
• Perhaps switch to gix if we plan to drop git2 someday.
• If we merge this or else, should we remove xtask-unpublished?
• The code is indeed in a high quality. I can't be pickier at code level. However, total lines of code usually correlate to maintenance cost. I am a bit worried it's a bit overkill when comparing to what can be done in shell scripts.
• This is a good demonstration of how people can invent something interesting with cargo and other libraries. I love the pretty status output!

[epage]

The cargo project doesn't adopt git conventional commit message pattern. Not sure if it is worthy or we should enforce that.

I copied that over from cargo release changes and am willing to drop it. The intention with both is that this is meant to help raw attention to extra information when its present, not to be prescriptive about it. The way the code is structured, conventional_status reports whether it has something or not and status can then report other information if we want to support other conventions.

Perhaps switch to gix if we plan to drop git2 someday.

Yeah, I stuck with what I was used to / what there are existing resources for. Digging into gix, I think I can switch over to it; the main question is on rev_parse_single as the docs aren't too clear on the behavior.

If we merge this or else, should we remove xtask-unpublished?

Unsure, in part because these are experiments but in part because I don't fully remember what all building blocks I originally intended...

The code is indeed in a high quality. I can't be pickier at code level. However, total lines of code usually correlate to maintenance cost. I am a bit worried it's a bit overkill when comparing to what can be done in shell scripts.

Shell scripts are also deceptively short and error prone :)

I also went past the absolute minimum (e.g. defaulting base-sha and head-sha, less error prone practices like enums over strings) for local usage as an xtask. If we are concerned about the burden we are taking on, we can drop features to be more inline with the shell script.

At the moment, this is also written in a way that I could see it being useful for writing up changelogs, so we might be able to get more mileage out of it.

This is a good demonstration of how people can invent something interesting with cargo and other libraries. I love the pretty status output!

And it is another way for us to dogfood to identify problems, like the fact that I can't make a call to say "tell me what files will be included in a package" but have to shell out for it (except I dropped it due to performance issues I hadn't debugged yet).

This also reminds me that I hope to simplify some of this code in the future. For clap, I created anstream which is like fwdansi on steroids. If we adopted it within clap, we could ore easily write formatted text, rather than having to use the individual Shell::write_stderr calls. Instead, we could do Shell::status and the message line could include formatting and it'd Just Work under all circumstances.

[bors]

☔ The latest upstream changes (presumably #12096) made this pull request unmergeable. Please resolve the merge conflicts.

[weihanglo]

At the moment, this is also written in a way that I could see it being useful for writing up changelogs, so we might be able to get more mileage out of it.

This made me wonder we would like to change each PR title before r+. It will make more sense for conventional commit messages.

Unsure, in part because these are experiments but in part because I don't fully remember what all building blocks I originally intended...

My fault. I should ask your original intent first for xtask-unpublished but what I did was just guessing 😅.

To be clear, I see the values in these conventions and the command. However, it feels like going too far away from #12033. I was hoping there could be a way to catch not-yet-bumped versions in CI ASAP, so that we can start splitting internal building blocks into subcrates.

[ehuss]

r? weihanglo

I think Weihang is following this more closely than I am. I haven't really reviewed this in detail, but the general concept seems good.

[weihanglo]

This looks fine for listing changes. However, I still don't know how it works with requiring user to do a version bump. Did it really give user the information that they need bumping a version for a crate?

[weihanglo]

I would probably suggest to remove conventional commit part. Let's focus on the original goal for now.

[weihanglo]

Do you consider copying part of #12126 for CI integration?

[weihanglo]

[Not a blocker] I still lean toward merging a similar approach like #12126 as a immediate guard rail. We can then properly design and expand this automation, thinking more on what we want for contributors and CI.

[epage]

Based on the direction of #12395, I think we can close this. What information we can learn from here has been called out in that other PR.