wrong commit message when cargo release --workspace is run with single crate

[psandana]

Summary

If a virtual workspace only contains a single crate, and the following line is run:

cargo release patch --workspace --execute

It produces the following commit message:

chore: Release {{crate_name}} version 0.0.1

Expected

The expectation would be to use the single crate name, or, the list of crates and versions.

Root-cause

The following line introduces the issue:

cargo-release/src/config.rs

Line 460 in 9a4e0ce

is_workspace: 1 < ws_meta.workspace_members.len(),

It assumes if there is single crate, even if the user in purpose provided the --workspace argument, that will use the single crate mode, but it does not fetches the crate name correctly.

Expected fixes

• Honour the --workspace argument and do not default to crate mode if len is 1, or,
• Provide the name of the crate correctly in the commit message.

Extras:

Ideally, the --workspace argument should generate a commit listing all packages and their versions.

[epage]

I'm sorry; somehow this fell through the cracks.

I'm not able to reproduce this. Could you provide a sample repo with the exact commands you ran?

[psandana]

Hi @epage,

Here you have: https://github.com/psandana/cargo-release-issue-701.

Use this command to reproduce:
cargo release patch --workspace --execute --no-publish --no-push --no-tag

[epage]

They key reproduction step is using package.version.workspace = true. When workspace inheritance is used, we can only update the version for all packages at once. This is incompatible with package commits being atomic, and so we force consolidated-commits = true on. We do not specialize this logic for single-package workspace members and I'm not inclined to do so.

I did find that we weren't taking this into account when choosing the default commit message which is being fixed in #860