Misc #21656: Exclude dependabot PRs from automated gem release notes

• Status: Closed
• Assignee: hsbt (Hiroshi SHIBATA)

[Earlopain (Earlopain _)]

Ruby has many gems, and many of them have release notes generated with the github command line instead of being written by a human. Usually that is fine, I don't have much of a problem with that approach. But what is less ideal is that github actions are pinned by commit hash/minor version which causes many dependabot PRs. This results in release notes like this: https://github.com/ruby/timeout/releases/tag/v0.4.4

Bump rubygems/release-gem from 1.1.0 to 1.1.1 by @dependabot[bot] in #56
Bump step-security/harden-runner from 2.10.2 to 2.10.3 by @dependabot[bot] in #57
Bump step-security/harden-runner from 2.10.3 to 2.10.4 by @dependabot[bot] in #59
Bump step-security/harden-runner from 2.10.4 to 2.11.0 by @dependabot[bot] in #60
Bump step-security/harden-runner from 2.11.0 to 2.11.1 by @dependabot[bot] in #61
Bump step-security/harden-runner from 2.11.1 to 2.12.0 by @dependabot[bot] in #62
Bump step-security/harden-runner from 2.12.0 to 2.12.1 by @dependabot[bot] in #63
Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64
Bump step-security/harden-runner from 2.12.1 to 2.12.2 by @dependabot[bot] in #65
Bump step-security/harden-runner from 2.12.2 to 2.13.0 by @dependabot[bot] in #66
Bump actions/checkout from 4 to 5 by @dependabot[bot] in #67
Bump step-security/harden-runner from 2.13.0 to 2.13.1 by @dependabot[bot] in #68
Add a workflow to sync commits to ruby/ruby by @k0kubun in #69

You might have missed it but hidden between all the automated non-user facing PRs is actually something that users might want to read about: Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64. I would like these release notes to omit bot PRs since they don't have any impact on gem consumers and only make it hard to actually find what changed.

Doing a quick search, 56 gems create release notes in this way: https://github.com/search?q=org%3Aruby+lang%3Ayml+--generate-notes&type=code. Really, I would want these written by a human since even without bot PRs there are still many that are just maintenance to fix CI or similar that don't concern the end user but I can understand that probably no one actually wants to write these by hand, which is why I propose to just exclude bot PRs. That should already have a pretty big impact.

[hsbt (Hiroshi SHIBATA)]

I removed them manually if I found that.

If you have an idea to exclude that with gh release create --generate-note, I will add it to our release workflow.

[Earlopain (Earlopain _)]

I removed them manually if I found that.

Ah, I didn't know that, thanks! I did check some other release notes and was surprised that they were often missing.

If you have an idea to exclude that with gh release create --generate-note, I will add it to our release workflow.

I will think about this 👍. Unfortunatly the cli itself doesn't have such an option.

[ufuk (Ufuk Kayserilioglu)]

There is a configuration file to control which labeled PRs make it into the automated release notes and which ones should be excluded. I can help set that up if it will be helpful.

[Earlopain (Earlopain _)]

Yeah! I just found that as well: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes

I was thinking about something a bit more complicated but luckily the api docs pointed me in the right direction.

net-imap actually uses it already: https://github.com/ruby/net-imap/blob/079167e99b47957d53c71c927ebbca537aae39d1/.github/release.yml#L23. The name does need to be dependabot[bot] I think. https://github.com/ruby/net-imap/releases/tag/v0.5.11 does still mention dependabot for them

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to hsbt (Hiroshi SHIBATA)

Thanks both.

I will try that template at next gem release.

[nevans (Nicholas Evans)]

Earlopain (Earlopain _) wrote in #note-4:

net-imap actually uses it already: https://github.com/ruby/net-imap/blob/079167e99b47957d53c71c927ebbca537aae39d1/.github/release.yml#L23. The name does need to be dependabot[bot] I think. https://github.com/ruby/net-imap/releases/tag/v0.5.11 does still mention dependabot for them

net-imap's release.yml is working as I'd intended. 🙂 Note that the exclusion is for the "Other changes" section and that ensures the dependabot PRs go into the "Miscellaneous" section. Also, net-imap's release.yml only creates a draft, which I manually proofread/edit before publishing.

I've classified PRs in net-imap's release notes as:

• changes library code:
  • Breaking Changes
    FWIW, I consider changes to minimum versions of the gem's own dependencies as "breaking". E.g: bumping the minimum ruby version.
  • Deprecated (probably adds new warnings)
  • Added
  • Fixed
  • Other Changes (e.g: refactoring, performance improvements, improved error messages, or any other minor code change that isn't classified as one of the above)
• changes library docs, but not code:
  • Documentation
• does not change library code or docs:
  • Miscellaneous (e.g: PRs that contain nothing but new/updated tests, new/updated benchmarks, CI workflow changes, release/build scripts)
    Since Dependabot only updates the CI and release workflows, but nothing in lib (nor the gemspec deps), it's classified as "Miscellaneous".
    If you can think of a better title for this than "miscellaneous", I'll switch to use that instead. :)

Other gems use a simpler categorization (e.g: rdoc and irb both use "Enhancements", "Bug Fixes", "Documentation", and "Other Changes"), and that's fine too.

But, relevant to the discussion in this ticket, I find release notes much more useful when they make a distinction between "other changes" that (directly) affect code/docs and "other changes" that don't. With that distinction made, I slightly prefer keeping dependabot updates in the release notes, because they do (indirectly) affect the released gem, which is built by files that are updated by dependabot, only after passing tests that are managed by files that are updated by dependabot. And I'd rather err on the side of including everything than leaving something out. But, without that distinction, I think it's good to exclude dependabot updates from the release notes.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Closed

I added the following for excluding dependabot update.

changelog:
  exclude:
    labels:
      - dependencies

It seems working fine: https://github.com/ruby/net-http/releases/tag/v0.7.0