--manifest-path is ignored

[xxshady]

I have the following structure:

workspace/
├─ Cargo.toml
├─ crate/
│  ├─ Cargo.toml

There is [workspace.metadata.release] in workspace/Cargo.toml and [package.metadata.release] in workspace/crate/Cargo.toml

when I run cargo release x.x.x --manifest-path Cargo.toml --execute in workspace/crate directory cargo-release uses pre-release-commit-message from workspace/Cargo.toml, and pushed commit message looks like "release new version: {{version}}" ({{version}} should be replaced but it's not)

UPD: #842 (comment)

[xxshady]

cargo-release uses pre-release-commit-message from workspace/Cargo.toml

is it expected behavior?

[epage]

Do you have a reproduction case I can look at or at least post your full [*.metadata.release] config tables?

[xxshady]

yea, here it is

[workspace.metadata.release]
pre-release-commit-message = "release new version: {{version}}"
tag = false

[package.metadata.release]
pre-release-commit-message = "release new version: {{version}} 2"
tag = false

[epage]

Are you using workspace inheritance fbr package.version?

And if you can't provide a reproduction case, can you provide very verbose logs of the release (-vv)?

[xxshady]

Are you using workspace inheritance fbr package.version?

no (at least for crate which is being published)

turns out I missed another required step to reproduce this: workspace must have at least 2 crates

here is the repro workspace and verbose logs of the release

[epage]

So I would say that this might be because I forgot that consolidate-commits is defaulted to true and when commits are consilidated, there is no version to put in the commit.

However, my naive attempt at reproducing this failed. Could you say what command I'm supposed to run to reproduce the log?

[xxshady]

1. cd altvup
2. cargo release 0.3.6-repro.0 --manifest-path Cargo.toml --execute --no-confirm -vv

[epage]

Yes, this is because of consolidate-commits default.

Whats happening

• If you publish this one package, it is considered to be part of consolidated commit. This status is determined statically and not based on whether you are releasing individual packages one at a time. The reason for that is so your static config (pre-release-commit-message) is not based on dynamic considerations (selected packages)
• When publishing the workspace, some-binary has package.version.workspace = true set. This puts it in the "workspace" version group (ie versions must be kept in sync). We allow the version to be in the commit message if its shared in a group. There happens to be logic that ignores packages not in a "group" when determining if there is a shared version to put in the commit message. Not entirely sure why its not more strict.

Options

• Set consolidate-commits = false
• Put altvup in a custom shared version group