{{version}} in commitMessageExtra contains "v"

[jbergstroem]

How are you running Renovate?

WhiteSource Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

Please select which platform you are using if self-hosting.

No response

If you're self-hosting Renovate, tell us what version of the platform you run.

No response

Describe the bug

When using {{version}} in commitMessageExtra it contains a "v" as part of the version string when bumping a github action. It is my understanding that renovateBot would only output the version number, not the string (from the documentation: "version: The version number of the changelog").

Using the following configuration (via package.json):

{
    "semanticCommits": "enabled",
    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "v{{newVersion}}"
}

..I get:

..and in 90% of the PRs created I only see strings like:

• chore(deps): vitest v0.0.117
• chore(deps): @commitlint/cli v16.

Perhaps it is intentional? If so;

1. Should I create a PR to clarify this in the documentation, and
2. Any ideas on how to handle this from a formatting point of view? 😄

Relevant debug logs

Logs

Copy/paste any log here, between the starting and ending backticks

Have you created a minimal reproduction repository?

No reproduction repository

[HonkingGoose]

    "commitMessageExtra": "v{{newVersion}}"

Have you tried using removing the v character from the "commitMessageExtra": "{{newVersion}}" configuration option and seeing what that gives you?

[jbergstroem]

    "commitMessageExtra": "v{{newVersion}}"

Have you tried using removing the v character from the "commitMessageExtra": "{{newVersion}}" configuration option and seeing what that gives you?

Thanks for the suggestion. Unfortunately that would lead to the default case of not having v before the version number (except in this case just reported)

[HonkingGoose]

Oh okay, it was worth a try maybe... 😄

[rarkins]

I think what we should do is add two new derived values prettyNewVersion and prettyNewMajor which are exposed to templating. These should prepend v to the newVersion and newMajor if it doesn't already exist. Then we can update our default templates to use it instead of e.g. v{{newVersion}}.

[jbergstroem]

I think what we should do is add two new derived values prettyNewVersion and prettyNewMajor which are exposed to templating. These should prepend v to the newVersion and newMajor if it doesn't already exist. Then we can update our default templates to use it instead of e.g. v{{newVersion}}.

Would that not also not imply that newVersion or newMajor would lack v in the case of said package? Im thinking that's my problem at the moment, no? Perhaps logic surrounding version, newVersion and newMajor is different - but yeah, having specific logic to deal with a prepended v seems to be the way to go.

[rarkins]

What I propose has no effect on newVersion or newMajor

[jbergstroem]

What I propose has no effect on newVersion or newMajor

Gotcha.

[hasanwhitesource]

@rarkins newMajor is a number so it can't have a v in its value. Or should we always append v to it through a new option prettyNewMajor ?
Regarding the solution I will expose a new config option called prettyNewVersion for the purpose of to append or not to append v to the newVersion.
Relevant example (renovate.json):

    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "{{prettyNewVersion}}"

Is this what you meant in your approach ?

[hasanwhitesource]

I plan to expose two fields prettyNewMajor and prettyNewVersion to be used.
@HonkingGoose can you please confirm if these should be documented in docs/usage/configuration-templates.md?

[HonkingGoose]

Can people use prettyNewMajor and prettyNewVersion as "template fields"? If yes, we can probably add these new fields to these docs:

https://docs.renovatebot.com/templates/

[hasanwhitesource]

Can people use prettyNewMajor and prettyNewVersion as "template fields"? If yes, we can probably add these new fields to these docs:

https://docs.renovatebot.com/templates/

Yes for example in this case users would use this way :

    "commitMessageExtra": "{{prettyNewVersion}}"

[hasanwhitesource]

@HonkingGoose what do you think of this description :

prettyNewVersion

returns the newVersion value with v appended to start.

If you want for example to create a pr title having the changed version:

{ "commitMessageExtra": "{{prettyNewVersion}}" }

prettyNewMajor

returns the newMajor value with v appended to start.

[HonkingGoose]

The basic idea for that text is okay, needs some grammar changes though. 😉

[hasanwhitesource]

@HonkingGoose haven't made a pr yet but do you think it is better to just add this as a templating functionality?
and not as a new field cause we don't want to set prettyNewVersion to a value in the config we just want to prettify newVersion and newMajor.
Example usage :

{
    "semanticCommits": "enabled",
    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "{{prettyNewVersion newVersion}}"
}

[hasanwhitesource]

In this case one can use the replace helper this way to make this work:

"commitMessageExtra":"{{replace '^v*' 'v' newVersion}}"

Examples input and outputs of this:
'v5.1.2' => 'v5.1.2'
'5.1.2' => 'v5.1.2'

@rarkins should we use this or expose the append function in the pr ?

[HonkingGoose]

@HonkingGoose haven't made a pr yet but do you think it is better to just add this as a templating functionality?

I don't know about this. 😄 I'll let the maintainers decide. 😉

[rarkins]

I prefer to popular prettyVersion and prettyNewMajor

[hasanwhitesource]

@rarkins which of these is best for usage:
Option1 (currently open pr) :
We expose a function prettyNewVersion that will prepend v to newVersion or newMajor.

{
    "semanticCommits": "enabled",
    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "{{prettyNewVersion newVersion}}"
}

Option 2 :
Adding prettyVersion ,prettyNewMajor fields in options where both will default to a template that will prepend v if it is missing.

{
    "semanticCommits": "enabled",
    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "{{prettyVersion}}"
}

{
    "semanticCommits": "enabled",
    "commitMessageAction": "",
    "commitMessageTopic": "{{depName}}",
    "commitMessageExtra": "{{prettyNewMajor}}"
}

[rarkins]

I think let's go with the second approach

[renovate-release]

🎉 This issue has been resolved in version 32.152.0 🎉

The release is available on:

• GitHub release
• 32.152.0

Your semantic-release bot 📦🚀