Auto-tagging fails to bump to correct version due to tag already existing

[hi-im-si]

Description:

We are using the TriPSs/conventional-changelog-action GitHub action to auto-tag our releases. However, we have encountered an issue where the tagging fails to bump to the correct version due to an already existing tag.

We have noticed that when the action tries to bump to the next version it is completely out of sync with the latest release and tries to bump to a version 3-4 releases ago. For example, if the current version is 0.55.0 and the next logical version is 0.56.0, we get an error to say that a tag for version 0.52.0 already exists which is confusing.

We have tried to manually delete the existing tags and retag everything that was skipped due to this issue but even manually tagging all the merged pull requests and re-running the latest workflow, we still see it is trying to create a tagged release at v0.52.0

Here you can see our current releases: https://github.com/Open-Study-College/osc/releases and Tags: https://github.com/Open-Study-College/osc/tags and an example of the github action job demonstrating the issue at hand: https://github.com/Open-Study-College/osc/actions/runs/4406083911/jobs/7768237420

An example of where the error is surfaced:

Bumping version to file "./package.json" with extension "json"
Bumping version to file "./package-lock.json" with extension "json"
Bumped file "/home/runner/work/osc/osc/package.json" from "0.51.1" to "0.52.0"
Bumped file "/home/runner/work/osc/osc/package-lock.json" from "0.51.1" to "0.52.0"
Changelog generated
## [0.52.0](https://github.com/Open-Study-College/osc/compare/v0.55.0...v0.52.0) (2023-03-15)
...
...
...
...
New version: 0.52.0
/usr/bin/git add .
/usr/bin/git commit -m RELEASE: v0.52.0
[main 29321904] RELEASE: v0.52.0
 3 files changed, 62 insertions(+), 234 deletions(-)
/usr/bin/git tag -a v0.52.0 -m v0.52.0
fatal: tag 'v0.52.0' already exists
(node:2146) UnhandledPromiseRejectionWarning: Error: The process '/usr/bin/git' failed with exit code 128
    at ExecState._setResult (/home/runner/work/_actions/TriPSs/conventional-changelog-action/v3.7.1/node_modules/@actions/exec/lib/toolrunner.js:574:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/TriPSs/conventional-changelog-action/v3.7.1/node_modules/@actions/exec/lib/toolrunner.js:557:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/TriPSs/conventional-changelog-action/v3.7.1/node_modules/@actions/exec/lib/toolrunner.js:451:27)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Socket.<anonymous> (internal/child_process.js:444:11)
    at Socket.emit (events.js:314:20)
    at Pipe.<anonymous> (net.js:675:12)
(node:2146) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)
(node:2146) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

The action should be able to determine the latest release and tag is 0.55.0 and therefore should bump the above to 0.56.0.

Any reason why this could be happening?

[TriPSs]

Think this is related to #166

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.