Workflow Not Updating Changelog: Empty File Generated

[Heet-Bhalodiya]

Describe the bug

The workflow does not add changes to the changelog. Each time the workflow runs, it generates an empty changelog file. Even after making multiple commits (e.g., 4-5 commits) and then running the workflow, the changelog file remains unchanged.

To Reproduce

Below is the content of my changelog.yml file for reference:

name: Generate changelog
on:
  release:
    types: [created, edited]
  workflow_dispatch:

jobs:
  generate-changelog:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0
    - uses: BobAnkh/auto-generate-changelog@v1.2.5
      with:
        REPO_NAME: 'my repo name'
        ACCESS_TOKEN: ${{secrets.GITHUB_TOKEN}}
        PATH: 'CHANGELOG.md'
        BRANCH: test-changelog
        COMMIT_MESSAGE: 'chore: CHANGELOG.md updated'
        TYPE: 'feat:Feature,fix:Bug Fixes,docs:Documentation,refactor:Refactor,perf:Performance Improvements'

Expected behavior

The changelog file should be updated after the workflow runs.

• OS: \ mac
• Browser \ chrome
• node \ 20

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[BobAnkh]

Can you tell me or give me an example repo that has such issues? With the information provided, I cannot figure out what is wrong. It might be related to the configuration.

[Heet-Bhalodiya]

Hi @BobAnkh,

Thanks for your quick reply.

I have a few questions regarding the auto-generate-changelog feature, and I would appreciate your guidance.

1) I have successfully used auto-generate-changelog in a public repository. However, when I use the same workflow in a private repository, it generates an empty changelog. Is there any additional configuration required for private repositories?

2) If a single commit contains multiple messages, how does auto-generate-changelog handle and differentiate them? For example, in the image below, multiple sub-messages are present within one commit. In my public repository, the changelog only shows code refactor. How are the other sub-messages managed?

![image](https://github.com/BobAnkh/auto-generate-changelog/assets/100203834/9e93bfbb-b10e-45e8-99e1-a325b40caa06)

3) How does auto-generate-changelog determine which messages to include in the changelog? For instance, if I have an existing changelog and want to update it after a few days to include new commits, will it consider all messages again or between the two tags or only the latest commits?

Thanks in advance.

[BobAnkh]

1. I have successfully used auto-generate-changelog in a public repository. However, when I use the same workflow in a private repository, it generates an empty changelog. Is there any additional configuration required for private repositories?
2. If a single commit contains multiple messages, how does auto-generate-changelog handle and differentiate them? For example, in the image below, multiple sub-messages are present within one commit. In my public repository, the changelog only shows code refactor. How are the other sub-messages managed?
3. How does auto-generate-changelog determine which messages to include in the changelog? For instance, if I have an existing changelog and want to update it after a few days to include new commits, will it consider all messages again or between the two tags or only the latest commits?

1. I'm not sure about the cause of the first issue. But an empty changelog might be due to nothing getting parsed. It would be helpful if you provided the log it outputs in workflow runs. One guess is you don't have any tag set, so by default, it won't output anything. If you want to check whether it works correctly, you can set env UNRELEASED_COMMITS to true. In this way, the changelog will generate an ## Unreleased part to include all unreleased commits. This configuration defaults to false since if set to true, it will always get regeneration whenever the workflow runs (which causes a lot of requests to GitHub and might hit the rate limit).
2. This repo only parses the subject of a commit (i.e., the first line). Handling the body part parsing is challenging since it can be in any format. According to the AngularJs commit convention, I myself won't wrap a lot of sub-messages inside one commit message, so I didn't consider parsing the body of a commit.
3. The TYPE field determines which kind of messages you want to include in the changelog. The REGENERATE_COUNT field will determine how many recent releases it will look and regenerate the changelog. See Note 5 in README.md for more details. By default, it will only regenerate the recent 1 release to cut overhead.

Contact me if you have any other questions.