googleapis / release-please

generate release PRs based on the conventionalcommits.org spec
https://www.conventionalcommits.org
Apache License 2.0
4.73k stars 351 forks source link

Improve documentation for `deps` et al #1735

Open einaren opened 1 year ago

einaren commented 1 year ago

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 commit type. This makes deps a quite important prefix when using conventional commits. Though, conventionalcommits.org and very few other google searches refers to deps 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.

hanssto commented 8 months ago

What is the expected result here, actually? I have a monorepo with different packages and I've now tried:

  1. the default from renovate chore(deps)
  2. A customized deps(package-name) (by configuring renovate's semanticCommitType/Scope settings)
  3. 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.

einaren commented 8 months ago

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

kellervater commented 1 month ago

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:

Despite the release-please documentation mentioning that the prefix deps: is a releasable unit, it's actually not...

🎯 "Workaround"

...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 disregard feat and fix. You really have to declare all Changelog section then.

Suggestions

I see 2 viable options here:

BTW: I'm super thankful for release-please and also the option that renovate allows to change the prefix.