Skip to content

Duplicate Changelog Entries for Merged Branches #510

Closed

Description

@lovetheguitar

Description

Somehow I end up with duplicate changelog entries after merging a MR.
E.g.

## v0.1.2 (2022-05-02)

### Fix

- **release**: do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH
- **release**: do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH
- **release**: try to not escape $CI_DEFAULT_BRANCH default value
- **release**: do not run run bump_version/dry_run in tag pipeline

Steps to reproduce

Use gitlab and add some commits to a new branch.
Open a MR and merge it.
Run commitizen on the main branch and get a changelog with duplicated entries.

Current behavior

Duplicate Changelog Entries:

## v0.1.2 (2022-05-02)

### Fix

- **release**: do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH
- **release**: do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH
- **release**: try to not escape $CI_DEFAULT_BRANCH default value
- **release**: do not run run bump_version/dry_run in tag pipeline

Desired behavior

No duplicates from merging a MR:

## v0.1.2 (2022-05-02)

### Fix

- **release**: do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH
- **release**: try to not escape $CI_DEFAULT_BRANCH default value
- **release**: do not run run bump_version/dry_run in tag pipeline

Screenshots

Problem appears to be that commitizen seems to parse the commit body also?!

Git log shows:

Date:   Mon May 2 15:28:31 2022 +0200

    Merge branch 'fix/improve_release_jobs' into 'master'

    fix(release): do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH

    Closes #4

    See merge request group/ci_templates!10

Date:   Mon May 2 15:12:10 2022 +0200

    fix(release): do version bump on $RELEASE_BRANCH (if defined) else on $CI_DEFAULT_BRANCH

    else dry run version bump
...

Environment

Commitizen Version: 2.24.0
Python Version: 3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)]
Operating System: Windows

Thanks for the nice tool. 😃

Activity

  1. tanguy-a commented on May 6, 2022

    @tanguy-a

    Hey, got the exact same issue here:
    Commitizen Version: 2.24.0
    Python Version: 3.7.12 && 3.9.1

    I tried with pip3 install -U Commitizen==2.20.0 and it did not duplicate.
    The versions after this one seem to have the duplication issue. So 2.20.1 duplicates.

  2. adam-grant-hendry commented on May 16, 2022

    @adam-grant-hendry
    Contributor

    @lovetheguitar Thanks for submitting this! I think I'll downgrade until a fix is submitted.

    @tanguy-a Thanks for the tip!

  3. Lee-W commented on May 22, 2022

    @Lee-W
    Member

    Hi @lovetheguitar could you please provide concrete steps for us to reproduce this issue on our side? Thanks !

  4. woile commented on May 22, 2022

    @woile
    Member

    I think this is related to the fact that we process the body, even though the subject of a commit message may not match conventional commits.

    # Process subject from commit message
    message = map_pat.match(commit.message)
    if message:
    parsed_message: Dict = message.groupdict()
    # change_type becomes optional by providing None
    change_type = parsed_message.pop("change_type", None)
    if change_type_map:
    change_type = change_type_map.get(change_type, change_type)
    if changelog_message_builder_hook:
    parsed_message = changelog_message_builder_hook(parsed_message, commit)
    changes[change_type].append(parsed_message)

    # Process body from commit message
    body_parts = commit.body.split("\n\n")
    for body_part in body_parts:
    message_body = body_map_pat.match(body_part)
    if not message_body:
    continue
    parsed_message_body: Dict = message_body.groupdict()
    change_type = parsed_message_body.pop("change_type", None)
    if change_type_map:
    change_type = change_type_map.get(change_type, change_type)
    changes[change_type].append(parsed_message_body)

    I think if the subject doesn't match, we should skip directly, no?

    I see this happening also now because github is adding the commit message in the body.

  5. added a commit that references this issue on Jul 16, 2022
    0307360
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions