Open einaren opened 1 year ago
What is the expected result here, actually? I have a monorepo with different packages and I've now tried:
chore(deps)
deps(package-name)
(by configuring renovate's semanticCommitType/Scope settings)fix(package-name)
release-please seems only to react to the last of those when using a release-please GH action that triggers on each push, while the docs would imply that the second should work (deps is a releasable unit) and the first should never work (chore is not a releasable unit). Is the problem that I use a commit scope for the package?
As an aside, conventional-commit linting fails on deps(package-name)
.
I would like dep upgrades to be included in the changelog with its own header, separate from the bug fixes.
I guess this is not a release-please challenge per se, but it would be good to recognize e.g. patch, minor and major dependency upgrades and use that to determine if the package should get a patch, minor or major release. I guess I can try to jig renovate to use fix/feat and ! for these, but they'd sort into different parts of the changelog.
I see there is a mix of fix(deps)
and chore(deps)
even in this replease-please repo, and I'm unable to see any pattern that make the devs chose one over the other.
IMHO, chore is better than fix, because these days updating patterns is like cleaning the house, it does not imply that something has been fixed in the repo which uses the dependency, it often just about staying up-to-date.
+1 for @hanssto's suggestion for having deps in the changelog under its own header
release-please seems only to react to the last of those when using a release-please GH action that triggers on each push, while the docs would imply that the second should work (deps is a releasable unit) and the first should never work (chore is not a releasable unit). Is the problem that I use a commit scope for the package?
Ran in the same problem today. I want to have release PRs created for my dependency upgrades, which have been created by renovate
.
In Renovate it's kinda easy to change the Commit Message Prefix.
To test this I tried many different commit message variations like:
deps: mymessage
chore(deps): myMessage
deps(withascope): andMyMessage
Despite the release-please documentation mentioning that the prefix deps:
is a releasable unit, it's actually not...
...until I took a look at the code and then tried to add a small option to the release-please command called: --changelog-sections=deps
. This did the trick in the end. A new Release-PR gets generated.
If you work with a release-please-config.json
you can assemble something like this:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
"packages": {
".": {
"changelog-sections": [
{
"type": "deps",
"section": "Dependencies"
},
{
"type": "docs",
"section": "Documentation"
},
{
"type": "feat",
"section": "Features"
},
{
"type": "fix",
"section": "Bugfixes"
}
],
"release-type": "simple",
"include-v-in-tag": true
}
}
}
When using this approach don't forget to also provide a .release-please-manifest.json
like this:
{
".": "1.1.0"
}
You can place both files in the root of your repo and the action will automatically pick 'em up.
[!CAUTION] When using the config-file approach, the
changelog-sections
replaces the entire default behavior. So only adding "deps" would disregardfeat
andfix
. You really have to declare all Changelog section then.
I see 2 viable options here:
deps:
a releasable unit.BTW: I'm super thankful for release-please
and also the option that renovate
allows to change the prefix.
Is your feature request related to a problem? Please describe.
The section Release Please bot does not create a release PR. Why? refers to
deps
as a conventional committype
. This makesdeps
a quite important prefix when using conventional commits. Though, conventionalcommits.org and very few other google searches refers todeps
as a commit type. It would be helpful if the release please readme clarifies which prefixes has syntactic meaning, and some recommendation on how to use it.