python-semantic-release 9.12.2__tar.gz → 9.13.0__tar.gz

{python_semantic_release-9.12.2/src/python_semantic_release.egg-info → python_semantic_release-9.13.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.12.2
+Version: 9.13.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/docs/automatic-releases/github-actions.rst

@@ -337,7 +337,7 @@ before the :ref:`version <cmd-version>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/python-semantic-release@v9.12.2
+    - uses: python-semantic-release/python-semantic-release@v9.13.0
       with:
         root_options: "-vv --noop"
 
@@ -684,7 +684,7 @@ to the GitHub Release Assets as well.
           - name: Action | Semantic Version Release
             id: release
             # Adjust tag with desired version if applicable.
-            uses: python-semantic-release/python-semantic-release@v9.12.2
+            uses: python-semantic-release/python-semantic-release@v9.13.0
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
               git_committer_name: "github-actions"
@@ -744,7 +744,7 @@ The equivalent GitHub Action configuration would be:
 
   - name: Action | Semantic Version Release
     # Adjust tag with desired version if applicable.
-    uses: python-semantic-release/python-semantic-release@v9.12.2
+    uses: python-semantic-release/python-semantic-release@v9.13.0
     with:
       github_token: ${{ secrets.GITHUB_TOKEN }}
       force: patch
@@ -772,13 +772,13 @@ Publish Action.
 .. code:: yaml
 
    - name: Release Project 1
-     uses: python-semantic-release/python-semantic-release@v9.12.2
+     uses: python-semantic-release/python-semantic-release@v9.13.0
      with:
        directory: ./project1
        github_token: ${{ secrets.GITHUB_TOKEN }}
 
    - name: Release Project 2
-     uses: python-semantic-release/python-semantic-release@v9.12.2
+     uses: python-semantic-release/python-semantic-release@v9.13.0
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/docs/changelog_templates.rst

@@ -512,60 +512,72 @@ the ``context`` object has the following attributes:
 Release History
 """""""""""""""
 
-A ``ReleaseHistory`` object has two attributes: ``released`` and ``unreleased``.
+A :py:class:`ReleaseHistory <semantic_release.changelog.release_history.ReleaseHistory>`
+object has two attributes: ``released`` and ``unreleased``.
 
 The ``unreleased`` attribute is of type ``Dict[str, List[ParseResult]]``. Each commit
 in the current branch's commit history since the last release on this branch is grouped
-by the ``type`` attribute of the ``ParsedCommit`` returned by the commit parser,
-or if the parser returned a ``ParseError`` then the result is grouped under the
-``"unknown"`` key.
+by the ``type`` attribute of the
+:py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>`
+returned by the commit parser, or if the parser returned a
+:py:class:`ParseError <semantic_release.commit_parser.token.ParseError>`
+then the result is grouped under the ``"unknown"`` key.
 
 For this reason, every element of ``ReleaseHistory.unreleased["unknown"]`` is a
-``ParseError``, and every element of every other value in ``ReleaseHistory.unreleased``
-is of type ``ParsedCommit``.
+:py:class:`ParseError <semantic_release.commit_parser.token.ParseError>`, and
+every element of every other value in ``ReleaseHistory.unreleased`` is of type
+:py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>`.
 
 Typically, commit types will be ``"feature"``, ``"fix"``, ``"breaking"``, though the
 specific types are determined by the parser. For example, the
-:py:class:`semantic_release.commit_parser.EmojiCommitParser` uses a textual
-representation of the emoji corresponding to the most significant change introduced
-in a commit (e.g. ``":boom:"``) as the different commit types. As a template author,
-you are free to customise how these are presented in the rendered template.
+:py:class:`EmojiCommitParser <semantic_release.commit_parser.emoji.EmojiCommitParser>`
+uses a textual representation of the emoji corresponding to the most significant change
+introduced in a commit (e.g. ``":boom:"``) as the different commit types. As a template
+author, you are free to customize how these are presented in the rendered template.
 
 .. note::
    If you are using a custom commit parser following the guide at
    :ref:`commit-parser-writing-your-own-parser`, your custom implementations of
-   :py:class:`semantic_release.ParseResult`, :py:class:`semantic_release.ParseError`
-   and :py:class:`semantic_release.ParsedCommit` will be used in place of the built-in
-   types.
+   :py:class:`ParseResult <semantic_release.commit_parser.token.ParseResult>`,
+   :py:class:`ParseError <semantic_release.commit_parser.token.ParseError>`
+   and :py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>`
+   will be used in place of the built-in types.
 
 The ``released`` attribute is of type ``Dict[Version, Release]``. The keys of this
 dictionary correspond to each version released within this branch's history, and
-are of type ``semantic_release.Version``. You can use the ``as_tag()`` method to
-render these as the Git tag that they correspond to inside your template.
-
-A ``Release`` object has an ``elements`` attribute, which has the same
-structure as the ``unreleased`` attribute of a ``ReleaseHistory``; that is,
-``elements`` is of type ``Dict[str, List[ParseResult]]``, where every element
-of ``elements["unknown"]`` is a ``ParseError``, and elements of every other
-value correspond to the ``type`` attribute of the ``ParsedCommit`` returned
+are of type :py:class:`Version <semantic_release.version.version.Version>`. You can
+use the ``as_tag()`` method to render these as the Git tag that they correspond to
+inside your template.
+
+A :py:class:`Release <semantic_release.changelog.release_history.Release>`object
+has an ``elements`` attribute, which has the same structure as the ``unreleased``
+attribute of a
+:py:class:`ReleaseHistory <semantic_release.changelog.release_history.ReleaseHistory>`;
+that is, ``elements`` is of type ``Dict[str, List[ParseResult]]``, where every element
+of ``elements["unknown"]`` is a
+:py:class:`ParseError <semantic_release.commit_parser.token.ParseError>`, and elements
+of every other value correspond to the ``type`` attribute of the
+:py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>` returned
 by the commit parser.
 
 The commits represented within each ``ReleaseHistory.released[version].elements``
-grouping are the commits which were made between ``version`` and the release
-corresponding to the previous version.
-That is, given two releases ``Version(1, 0, 0)`` and ``Version(1, 1, 0)``,
-``ReleaseHistory.released[Version(1, 0, 0)].elements`` contains only commits
-made after the release of ``Version(1, 0, 0)`` up to and including the release
-of ``Version(1, 1, 0)``.
+grouping are the commits which were made between version and the release corresponding
+to the previous version. That is, given two releases ``Version(1, 0, 0)`` and
+``Version(1, 1, 0)``, ``ReleaseHistory.released[Version(1, 0, 0)].elements`` contains
+only commits made after the release of ``Version(1, 0, 0)`` up to and including the
+release of ``Version(1, 1, 0)``.
 
 To maintain a consistent order of subsections in the changelog headed by the commit
-type, it's recommended to use Jinja's `dictsort <https://jinja.palletsprojects.com/en/3.1.x/templates/#jinja-filters.dictsort>`_
+type, it's recommended to use Jinja's
+`dictsort <https://jinja.palletsprojects.com/en/3.1.x/templates/#jinja-filters.dictsort>`_
 filter.
 
 Each ``Release`` object also has the following attributes:
 
 * ``tagger: git.Actor``: The tagger who tagged the release.
+
 * ``committer: git.Actor``: The committer who made the release commit.
+
 * ``tagged_date: datetime``: The date and time at which the release was tagged.
 
 .. seealso::
@@ -724,11 +736,17 @@ The filters provided vary based on the VCS configured and available features:
 
   .. code:: jinja
 
-      {{ "29" | merge_request_url }}
+      {{
+          "[%s](%s)" | format(
+            commit.linked_merge_request,
+            commit.linked_merge_request | merge_request_url
+          )
+      }}
+      {# commit.linked_merge_request is only available in v9.13.0 or greater #}
 
   .. code:: markdown
 
-      https://example.com/example/repo/-/merge_requests/29
+      [#29](https://example.com/example/repo/-/merge_requests/29)
 
 * ``pull_request_url (Callable[[PullReqStr | PullReqInt], UrlStr])``: given a pull
   request number, return a URL to the pull request in the remote. For remote vcs'
@@ -743,11 +761,17 @@ The filters provided vary based on the VCS configured and available features:
 
   .. code:: jinja
 
-      {{ "29" | pull_request_url }}
+      {{
+          "[%s](%s)" | format(
+            commit.linked_merge_request,
+            commit.linked_merge_request | pull_request_url
+          )
+      }}
+      {# commit.linked_merge_request is only available in v9.13.0 or greater #}
 
   .. code:: markdown
 
-      https://example.com/example/repo/pull/29
+      [#29](https://example.com/example/repo/pull/29)
 
 * ``read_file (Callable[[str], str])``: given a file path, read the file and
   return the contents as a string. This function was added specifically to
@@ -883,12 +907,12 @@ exposed to the `Jinja`_ template when rendering the release notes.
 
 Additionally, the following two globals are available to the template:
 
-* ``release`` (:class:`Release <semantic_release.changelog.release_history.Release>`):
+* ``release`` (:py:class:`Release <semantic_release.changelog.release_history.Release>`):
   contains metadata about the content of the release, as parsed from commit logs
 
   *Introduced in v8.0.0.*
 
-* ``version`` (:class:`Version <semantic_release.version.version.Version>`): contains
+* ``version`` (:py:class:`Version <semantic_release.version.version.Version>`): contains
   metadata about the software version to be released and its ``git`` tag
 
   *Introduced in v8.0.0.*

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/docs/commit-parsing.rst

@@ -45,9 +45,12 @@ The following parsers are built in to Python Semantic Release:
 ``semantic_release.commit_parser.AngularCommitParser``
 """"""""""""""""""""""""""""""""""""""""""""""""""""""
 
-The default parser, which uses the `Angular commit style <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits>`_ with the following differences:
+The default parser, which uses the
+`Angular commit style <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits>`_
+with the following differences:
 
   - Multiple ``BREAKING CHANGE:`` paragraphs are supported
+
   - ``revert`` is not currently supported
 
 The default configuration options for
@@ -222,26 +225,41 @@ as the commit history of a repository is being parsed. Python Semantic Release d
 not raise an exception if a commit cannot be parsed.
 
 Python Semantic Release uses :py:class:`semantic_release.ParsedCommit`
-as the return type of a successful parse operation, and :py:class:`semantic_release.ParseError`
-as the return type from an unsuccessful parse of a commit. :py:class:`semantic_release.ParsedCommit` is a `namedtuple`_ which has the following fields:
-
-* bump: a :py:class:`semantic_release.LevelBump` indicating what type of change this commit introduces.
-* type: the *type* of the commit as a string, per the commit message style. This is up to the
-  parser to implement; for example, the :py:class:`semantic_release.commit_parser.EmojiCommitParser`
-  parser fills this field with the emoji representing the most significant change for the commit.
-  The field is named after the representation in the Angular commit specification.
-* scope: The scope, as a string, parsed from the commit. Commit styles which do not have a meaningful
-  concept of "scope" should fill this field with an empty string.
-* descriptions: A list of paragraphs (strings) (delimited by a double-newline) from the commit message.
-* breaking_descriptions: A list of paragraphs (strings) which are deemed to identify and describe
-  breaking changes by the parser. An example would be a paragraph which begins with the text
-  ``BREAKING CHANGE:``.
-* commit: The original commit object that was parsed.
+as the return type of a successful parse operation, and
+:py:class:`semantic_release.ParseError` as the return type from an unsuccessful
+parse of a commit. :py:class:`semantic_release.ParsedCommit` is a `namedtuple`_
+which has the following fields:
+
+* **bump**: a :py:class:`semantic_release.LevelBump` indicating what type of change
+  this commit introduces.
+
+* **type**: the *type* of the commit as a string, per the commit message style. This
+  is up to the parser to implement; for example, the
+  :py:class:`semantic_release.commit_parser.EmojiCommitParser` parser fills this field
+  with the emoji representing the most significant change for the commit. The field is
+  named after the representation in the Angular commit specification.
+
+* **scope**: The scope, as a string, parsed from the commit. Commit styles which do
+  not have a meaningful concept of "scope" should fill this field with an empty string.
+
+* **descriptions**: A list of paragraphs (strings) (delimited by a double-newline)
+  from the commit message.
+
+* **breaking_descriptions**: A list of paragraphs (strings) which are deemed to
+  identify and describe breaking changes by the parser. An example would be a
+  paragraph which begins with the text ``BREAKING CHANGE:``.
+
+* **commit**: The original commit object (a class defined by GitPython) that was parsed.
+
+* **linked_merge_request**: A pull request or merge request definition, if the commit is
+  labeled with a pull/merge request number. This is a string value which includes any
+  special character prefix used by the VCS (e.g. ``#`` for GitLab, ``!`` for Bitbucket).
 
 :py:class:`semantic_release.ParseError` is a `namedtuple`_ which has the following fields:
 
-* commit: The original commit object that was parsed.
-* error: A string with a meaningful error message as to why the commit parsing failed.
+* **commit**: The original commit object that was parsed.
+
+* **error**: A string with a meaningful error message as to why the commit parsing failed.
 
 In addition, :py:class:`semantic_release.ParseError` implements an additional method, ``raise_error``.
 This method raises a :py:class:`semantic_release.CommitParseError` with the message contained in the
@@ -252,10 +270,12 @@ attributes available, each implemented as a ``property`` which is computed, as a
 convenience for template authors - therefore custom implementations should ensure
 these properties can also be computed:
 
-* message: the ``message`` attribute of the ``commit``; where the message is of type ``bytes``
-  this should be decoded to a ``UTF-8`` string.
-* hexsha: the ``hexsha`` attribute of the ``commit``, representing its hash.
-* short_hash: the first 7 characters of the ``hexsha`` attribute of the ``commit``.
+* **message**: the ``message`` attribute of the ``commit``; where the message is of type
+  ``bytes`` this should be decoded to a ``UTF-8`` string.
+
+* **hexsha**: the ``hexsha`` attribute of the ``commit``, representing its hash.
+
+* **short_hash**: the first 7 characters of the ``hexsha`` attribute of the ``commit``.
 
 In Python Semantic Release, the class :py:class:`semantic_release.ParseResult`
 is defined as ``ParseResultType[ParsedCommit, ParseError]``, as a convenient shorthand.
@@ -268,7 +288,9 @@ type returned on an unsuccessful parse of the ``commit``.
 A custom parser result type, therefore, could be implemented as follows:
 
 * ``MyParsedCommit`` subclasses ``ParsedCommit``
+
 * ``MyParseError`` subclasses ``ParseError``
+
 * ``MyParseResult = ParseResultType[MyParsedCommit, MyParseError]``
 
 Internally, Python Semantic Release uses ``isinstance`` to determine if the result
@@ -326,8 +348,10 @@ the following:
 
 * A class-level attribute ``parser_options``, which must be set to
   :py:class:`semantic_release.ParserOptions` or a subclass of this.
+
 * An ``__init__`` method which takes a single parameter, ``options``, that should be
   of the same type as the class' ``parser_options`` attribute.
+
 * A method, ``parse``, which takes a single parameter ``commit`` that is of type
   `git.objects.commit.Commit <gitpython-commit-object>`_, and returns
   :py:class:`semantic_release.token.ParseResult`, or a subclass of this.

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/docs/conf.py

@@ -38,7 +38,7 @@ htmlhelp_basename = "python-semantic-releasedoc"
 
 docs_path = os.path.dirname(__file__)
 apidoc_output_dir = os.path.join(docs_path, "api")
-apidoc_module_dir = os.path.join(docs_path, "..", "semantic_release")
+apidoc_module_dir = os.path.join(docs_path, "..", "src")
 apidoc_separate_modules = True
 apidoc_module_first = True
 apidoc_extra_args = ["-d", "3"]

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/pyproject.toml

@@ -6,7 +6,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-semantic-release"
-version = "9.12.2"
+version = "9.13.0"
 description = "Automatic Semantic Versioning for Python projects"
 requires-python = ">=3.8"
 license = { text = "MIT" }

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0/src/python_semantic_release.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.12.2
+Version: 9.13.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/src/python_semantic_release.egg-info/SOURCES.txt

@@ -68,6 +68,7 @@ src/semantic_release/data/templates/angular/md/.components/changelog_header.md.j
 src/semantic_release/data/templates/angular/md/.components/changelog_init.md.j2
 src/semantic_release/data/templates/angular/md/.components/changelog_update.md.j2
 src/semantic_release/data/templates/angular/md/.components/changes.md.j2
+src/semantic_release/data/templates/angular/md/.components/macros.md.j2
 src/semantic_release/data/templates/angular/md/.components/unreleased_changes.md.j2
 src/semantic_release/data/templates/angular/md/.components/versioned_changes.md.j2
 src/semantic_release/data/templates/angular/rst/CHANGELOG.rst.j2
@@ -127,6 +128,7 @@ tests/fixtures/repos/git_flow/__init__.py
 tests/fixtures/repos/git_flow/repo_w_2_release_channels.py
 tests/fixtures/repos/git_flow/repo_w_3_release_channels.py
 tests/fixtures/repos/github_flow/__init__.py
+tests/fixtures/repos/github_flow/repo_w_default_release.py
 tests/fixtures/repos/github_flow/repo_w_release_channels.py
 tests/fixtures/repos/trunk_based_dev/__init__.py
 tests/fixtures/repos/trunk_based_dev/repo_w_no_tags.py

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/src/semantic_release/__init__.py

@@ -24,7 +24,7 @@ from semantic_release.version import (
     tags_and_versions,
 )
 
-__version__ = "9.12.2"
+__version__ = "9.13.0"
 
 __all__ = [
     "CommitParser",

{python_semantic_release-9.12.2 → python_semantic_release-9.13.0}/src/semantic_release/commit_parser/angular.py

@@ -8,19 +8,26 @@ from __future__ import annotations
 import logging
 import re
 from functools import reduce
+from itertools import zip_longest
 from re import compile as regexp
 from typing import TYPE_CHECKING, Tuple
 
 from pydantic.dataclasses import dataclass
 
 from semantic_release.commit_parser._base import CommitParser, ParserOptions
-from semantic_release.commit_parser.token import ParsedCommit, ParseError, ParseResult
+from semantic_release.commit_parser.token import (
+    ParsedCommit,
+    ParsedMessageResult,
+    ParseError,
+    ParseResult,
+)
 from semantic_release.commit_parser.util import breaking_re, parse_paragraphs
 from semantic_release.enums import LevelBump
 
 if TYPE_CHECKING:
     from git.objects.commit import Commit
 
+
 logger = logging.getLogger(__name__)
 
 
@@ -65,11 +72,16 @@ class AngularParserOptions(ParserOptions):
     default_bump_level: LevelBump = LevelBump.NO_RELEASE
 
     def __post_init__(self) -> None:
-        self.tag_to_level = {tag: self.default_bump_level for tag in self.allowed_tags}
-        for tag in self.patch_tags:
-            self.tag_to_level[tag] = LevelBump.PATCH
-        for tag in self.minor_tags:
-            self.tag_to_level[tag] = LevelBump.MINOR
+        self.tag_to_level: dict[str, LevelBump] = dict(
+            [
+                # we have to do a type ignore as zip_longest provides a type that is not specific enough
+                # for our expected output. Due to the empty second array, we know the first is always longest
+                # and that means no values in the first entry of the tuples will ever be a LevelBump.
+                *zip_longest(self.allowed_tags, (), fillvalue=self.default_bump_level),  # type: ignore[list-item]
+                *zip_longest(self.patch_tags, (), fillvalue=LevelBump.PATCH),  # type: ignore[list-item]
+                *zip_longest(self.minor_tags, (), fillvalue=LevelBump.MINOR),  # type: ignore[list-item]
+            ]
+        )
 
 
 class AngularCommitParser(CommitParser[ParseResult, AngularParserOptions]):
@@ -98,6 +110,10 @@ class AngularCommitParser(CommitParser[ParseResult, AngularParserOptions]):
             ),
             flags=re.DOTALL,
         )
+        # GitHub & Gitea use (#123), GitLab uses (!123), and BitBucket uses (pull request #123)
+        self.mr_selector = regexp(
+            r"[\t ]+\((?:pull request )?(?P<mr_number>[#!]\d+)\)[\t ]*$"
+        )
 
     @staticmethod
     def get_default_options() -> AngularParserOptions:
@@ -114,27 +130,23 @@ class AngularCommitParser(CommitParser[ParseResult, AngularParserOptions]):
         accumulator["descriptions"].append(text)
         return accumulator
 
-    # Maybe this can be cached as an optimization, similar to how
-    # mypy/pytest use their own caching directories, for very large commit
-    # histories?
-    # The problem is the cache likely won't be present in CI environments
-    def parse(self, commit: Commit) -> ParseResult:
-        """
-        Attempt to parse the commit message with a regular expression into a
-        ParseResult
-        """
-        message = str(commit.message)
-        parsed = self.re_parser.match(message)
-        if not parsed:
-            return _logged_parse_error(
-                commit, f"Unable to parse commit message: {message}"
-            )
+    def parse_message(self, message: str) -> ParsedMessageResult | None:
+        if not (parsed := self.re_parser.match(message)):
+            return None
+
         parsed_break = parsed.group("break")
         parsed_scope = parsed.group("scope")
         parsed_subject = parsed.group("subject")
         parsed_text = parsed.group("text")
         parsed_type = parsed.group("type")
 
+        linked_merge_request = ""
+        if mr_match := self.mr_selector.search(parsed_subject):
+            linked_merge_request = mr_match.group("mr_number")
+            # TODO: breaking change v10, removes PR number from subject/descriptions
+            # expects changelog template to format the line accordingly
+            # parsed_subject = self.pr_selector.sub("", parsed_subject).strip()
+
         body_components: dict[str, list[str]] = reduce(
             self.commit_body_components_separator,
             [
@@ -157,19 +169,34 @@ class AngularCommitParser(CommitParser[ParseResult, AngularParserOptions]):
             )
         )
 
-        # TODO: remove in the future
-        if level_bump == LevelBump.MAJOR:
-            parsed_type = "breaking"
+        return ParsedMessageResult(
+            bump=level_bump,
+            type=parsed_type,
+            category=LONG_TYPE_NAMES.get(parsed_type, parsed_type),
+            scope=parsed_scope,
+            descriptions=tuple(body_components["descriptions"]),
+            breaking_descriptions=tuple(body_components["breaking_descriptions"]),
+            linked_merge_request=linked_merge_request,
+        )
+
+    # Maybe this can be cached as an optimization, similar to how
+    # mypy/pytest use their own caching directories, for very large commit
+    # histories?
+    # The problem is the cache likely won't be present in CI environments
+    def parse(self, commit: Commit) -> ParseResult:
+        """
+        Attempt to parse the commit message with a regular expression into a
+        ParseResult
+        """
+        if not (pmsg_result := self.parse_message(str(commit.message))):
+            return _logged_parse_error(
+                commit, f"Unable to parse commit message: {commit.message!r}"
+            )
 
         logger.debug(
-            "commit %s introduces a %s level_bump", commit.hexsha[:8], level_bump
+            "commit %s introduces a %s level_bump",
+            commit.hexsha[:8],
+            pmsg_result.bump,
         )
 
-        return ParsedCommit(
-            bump=level_bump,
-            type=LONG_TYPE_NAMES.get(parsed_type, parsed_type),
-            scope=parsed_scope,
-            descriptions=body_components["descriptions"],
-            breaking_descriptions=body_components["breaking_descriptions"],
-            commit=commit,
-        )
+        return ParsedCommit.from_parsed_message_result(commit, pmsg_result)