Description

Motivation and Context

I was making use of git-cliff for a project that was using a bit more unorthodox commit style with message and body that requires me to be able to do some more advanced parsing when I generate changelogs.

How Has This Been Tested?

I wrote new test cases in template.rs but I have also run this on my own project changelogs on a project and successfully pulled all string sequences I was looking for out of the commit message to be able to process them in a way that I had to.
I mainly needed the find_regex function the split and replace is a bonus that came from testing different approaches.

The project i work on use Azure DevOps and we add a user story, task or such number to the Pull Request when we create them, there can be multiple ones as well, and since it sadly doesn't use conventional commits we ended up using the user story number as a group.
But sometimes a PR includes multiple user stories and then we want to pull all of those from the message with a regex as such (#\\d+) and then just write them all before the actual commit message that is included for a better overview.

So we could write a really simple template like this

body = """
{% if version %}\
    # [{{ version | trim_start_matches(pat="v") }}]
{% else %}\
    # [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    {% if group == "Others" %}
        ## {{ group | striptags | trim }}\
    {% else %}
        {{ group | striptags | trim }}\
    {% endif %}
    {% for commit in commits %}
      {% set issues = commit.message | find_regex(pat="#\\d+")   %}\
      {% for issue in issues | slice(start=1) %}\
        {{issue}}\n
      {% endfor %}
      {% set message = commit.message | split(pat="\n") %}
      {% if message | length > 1 %}\
        - {{ message[0] | trim }}\
      {% endif %}
    {% endfor %}
{% endfor %}
"""

Screenshots / Logs (if applicable)

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.