feat: handle multiple commits in a single message

[dgokcin]

Summary

This PR enhances the breaking change detection mechanism and improves the parsing of commit messages to handle multiple conventional commits and nested commit blocks mentioned in #2357

Changes

• Added additional breaking change detection from the commit body in toConventionalChangelogFormat and postProcessCommits functions.
• Enhanced splitMessages function to:
  • Separate conventional commits within the main message.
  • Extract nested commits enclosed in BEGIN_NESTED_COMMIT/END_NESTED_COMMIT blocks.
  • Preserve the original message structure outside of nested commit blocks.
  • Handle multiple nested commits and conventional commits in a single message.
• Updated tests in test/commits.ts to reflect the changes and added new test cases for multiple commits in a single message.
• Added a new fixture multiple-commits-single-message.txt for testing multiple commits in a single message.

Additional Notes

• The changes ensure that breaking changes mentioned in the commit body are correctly appended to the breaking change notes.
• The splitMessages function now correctly handles and separates multiple conventional commits and nested commit blocks, improving the accuracy of commit parsing.
• Updated test cases ensure the robustness of the new functionality and maintain backward compatibility.
• First time contributing to release-please so please review carefully as the splitMessages function seems to be a critical function 🙃

Fixes #2357

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[chingor13]

Thanks for this and sorry for the delay in reviewing.

For the splitting commit messages, this seems ok to me -- we're splitting on a newline and then the next line looks like a conventional commit message. The scenario we're intentionally trying to avoid is GitHub's default squash/merge message where incremental commit messages might be parsed which we don't want (example: https://github.com/googleapis/release-please/blob/main/test/fixtures/commit-messages/1257-breaking-change.txt). It seems this feature still ignores the subcommit messages because the next line doesn't start with the conventional commit looking message.

For the additional breaking change detection, please split it into a separate PR and add a test for it. Additionally, the current breaking change detection is handled by the conventional-commits/parser library which uses a grammar to actually conform to the conventionalcommits.org spec. I'm not sure we want to add this additional way of marking a breaking change.

[dgokcin]

Hi @chingor13, thanks for the review.

I want to clarify the necessity of including the breaking change detection lines in src/commit.ts (Lines 172 to 184 and 329 to 344) from this branch. Without these lines, the following two tests fail, which is why I felt it was essential to add the additional checks.

1. "DefaultChangelogNotes buildNotes with commit parsing should handle meta commits"

   • This test fails because the generated changelog is missing the "BREAKING CHANGES" section. The expected output includes a breaking change for the recaptchaenterprise component, but the actual output does not contain this section, leading to a mismatch.

2. "parseConventionalCommits parses meta commits"

   • This test fails because it expects a commit to be recognized as a breaking change (true), but it is incorrectly identified as false. This discrepancy arises from the lack of additional breaking change detection logic, which is crucial for accurately parsing and recognizing breaking changes in commit messages.

From my understanding, the library you mentioned is not capable of detecting breaking changes in the body of the commit out of the box. If it were, I would expect the tests to pass without the additional checks. By including these lines, I ensure that the tests pass and that the changelog accurately reflects the intended breaking changes, thus maintaining the integrity of the commit parsing process and stay backward compatible.

I would be happy to try out any ideas you might have to keep the scope of this PR limited to the splitting of the commit messages, without including any breaking change detection. If you have any suggestions on how to accomplish this without affecting the breaking change logic, I would appreciate your input.