It would be cool to add sorting to the dependencies section to make it easier to read

I have nested lists in my changelog, which get corrupted with this action:

Given the changelog

## [Unreleased]
### Fixed
- MQTT
  - calculate correct tyre pressure

I expect the following updated changelog

## [Unreleased]
### Fixed
- MQTT
  - calculate correct tyre pressure
### Dependencies
- Bump `maven-source-plugin` from 3.2.1 to 3.3.0 (#23)

but I get

## [Unreleased]
### Fixed
- MQTT
### Dependencies
- Bump `maven-source-plugin` from 3.2.1 to 3.3.0 (#23)
  - calculate correct tyre pressure

I'd like to be able to run this action on main (the default branch) after merging a Dependabot PR to open a new PR to update the CHANGELOG. This would solve the issue of actions not triggering when the PR is updated. I think a basic implementation should check commits with a specific format back to the last release tag and only support updating the unreleased CHANGELOG entry.

I have run into a situation where there is almost always a conflict in CHANGELOG.md after I merge a PR that uses this action. Dependabot is unable to recreate the branch automatically, because Dependabot stops doing that when another actor pushes a commit.
Is there a recommendation for how to resolve this automatically? For now I have to leave a comment like @dependabot recreate in each PR it happens.
An example is at UniversalMediaServer/UniversalMediaServer#4364

Hi, thank you so much for this action, it is very useful.
Is there any chance you could add support for Mend Renovate? https://github.com/marketplace/renovate

Their support for monorepos makes them invaluable for me, along with some configuration options Dependabot doesn't offer, for example here SubJunk/TimelineTools#1194 it updated 11 packages in one PR, so I would love to use it with this instead of having to stick with Dependabot

As a dangoslen/dependabot-changelog-helper user, I would like the lack or presence of a file-ending newline character to be maintained so that the PR diffs are smaller and it's not always getting changed back and forth as other users update the changelog.

Background: In our org, we tell everyone to set up their IDEs to include a newline char at the end of files. This changelog helper keeps trying to delete it the newline at the end of the changelog, though. So the last line of the changelog shows up in the diff a lot, and it'd be nice if that could be kept clean.

Based on https://keepachangelog.com/en/1.1.0/, dependency upgrades are simply listed within a ### Changed header, not a ### Dependencies header. This has caused compatibility issues when attempting to use other GitHub Actions that strictly adhere to the Keep A Changelog format. Would it be possible to add the ability to disable adding the header, or to be able to choose whether to list the dependency upgrades within ### Dependencies or ### Changed ?

There's a typo in this field:

I'll let you fix this. 😉

Introduction

I think I found some things for you to look into. I've linked to relevant documentation so you can review the docs and decide what to do. 😉

Things to check

pull_request_target in workflow files

You're using pull_request_target in your workflow files, for example:

This may be dangerous. Here's a quote from GitHub's security lab blog post: ¹

TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.

Manually approve workflow run from public forks

You may want to require manual approval before a workflow runs from a public fork. Quote: ²

Anyone can fork a public repository, and then submit a pull request that proposes changes to the repository's GitHub Actions workflows. Although workflows from forks do not have access to sensitive data such as secrets, they can be an annoyance for maintainers if they are modified for abusive purposes.

To help prevent this, workflows on pull requests to public repositories from some outside contributors will not run automatically, and might need to be approved first. By default, all first-time contributors require approval to run workflows.

Note
Workflows triggered by pull_request_target events are run in the context of the base branch. Since the base branch is considered trusted, workflows triggered by these events will always run, regardless of approval settings.

Because you're using pull_request_target the workflow ran immediately on my PR, as mentioned in the quote above.

Security hardening for GitHub Actions

GitHub has good documentation on how to improve the security hardening of your actions. ³

This guide explains how to configure security hardening for certain GitHub Actions features.

Can be seen here UniversalMediaServer/UniversalMediaServer@6caa293

When reading a CHANGELOG it's useful to be able to click through to get the context of the changes so being able to click a link to see the version being updated to and the actual PR would make sense.

Occasionally Dependabot will open up a PR that attempts to update multiple dependencies(In my experience I have only seen it attempt to update two dependencies, not sure if it will ever attempt more):

These PRs will cause the action to fail with an error: Unable to extract entry from pull request title!

@dangoslen I really like this github action, I have been looking at this for a while to save time when reviewing dependency updates! Thank you for it.

However in my projects I use semantic versioning and typical commit prefixes are chore: ..., fix: .... As a result by default dependabot adds an additional prefix to its commit messages, such as:
chore(deps): Bump requests from 2.28.1 to 2.31.0 in /requirements

Unfortunately it does not seem possible to completely disable the dependabot prefix to remove the chore(deps): part. We can modify it but not set it empty.

Considering that your action is only able to identify the prefix based on a single word, what would you recommend?

From what I can see, if I bump a dependency from x to y and y to z in separate PRs but the same release cycle, this action would create only one line in the changelog: "Bump ... from x to z".
I like to document and link each merged PR in my changelog.
Currently (and I do this by hand) I have one changelog entry for each PR:

* Bump ... from x to y (#1)
* Bump ... from y to z (#2)

Another alternative but maybe slightly more complex to implement would be something like this:

* Bump ... from x to z (#1, #2)

If you are open to it, I might try to implement something like described for this action. If so, which way would you prefer? Multiple entries or a single entry with multiple links?