Issue with multiple pre-releases created and patch bump

[gaspo53]

Hi! I'm having an issue while creating RC tags (patch). Seems like it grabs the correct non-rc to create the tag from, but doesn't take into account if there's any other RC tag on that base non-rc tag. First run (when the first rc.0 tag doesn't exit, runs fine. Subsequent runs, fail). To clarify:
`* [new tag] v3.29.3 -> v3.29.3

• [new tag] v3.3.0 -> v3.3.0
• [new tag] v3.3.1 -> v3.3.1
• [new tag] v3.3.2 -> v3.3.2
• [new tag] v3.3.3 -> v3.3.3
• [new tag] v3.3.4 -> v3.3.4
• [new tag] v3.31.0 -> v3.31.0
• [new tag] v3.32.0 -> v3.32.0
• [new tag] v3.32.1 -> v3.32.1
• [new tag] v3.32.2 -> v3.32.2
• [new tag] v3.32.3 -> v3.32.3
• [new tag] v3.32.4-rc.0 -> v3.32.4-rc.0
• [new tag] v3.33.0-rc.0 -> v3.33.0-rc.0
• [new tag] v3.33.0-rc.1 -> v3.33.0-rc.1
• [new tag] v3.33.0-rc.10 -> v3.33.0-rc.10
• [new tag] v3.33.0-rc.11 -> v3.33.0-rc.11
• [new tag] v3.33.0-rc.12 -> v3.33.0-rc.12
• [new tag] v3.33.0-rc.13 -> v3.33.0-rc.13
• [new tag] v3.33.0-rc.14 -> v3.33.0-rc.14
• [new tag] v3.33.0-rc.15 -> v3.33.0-rc.15
• [new tag] v3.33.0-rc.2 -> v3.33.0-rc.2
• [new tag] v3.33.0-rc.3 -> v3.33.0-rc.3
• [new tag] v3.33.0-rc.4 -> v3.33.0-rc.4
• [new tag] v3.33.0-rc.5 -> v3.33.0-rc.5
• [new tag] v3.33.0-rc.6 -> v3.33.0-rc.6
• [new tag] v3.33.0-rc.7 -> v3.33.0-rc.7
• [new tag] v3.33.0-rc.8 -> v3.33.0-rc.8
• [new tag] v3.33.0-rc.9 -> v3.33.0-rc.9
• [new tag] v3.4.0 -> v3.4.0
• [new tag] v3.4.1 -> v3.4.1
• [new tag] v3.4.2 -> v3.4.2
• [new tag] v3.4.3 -> v3.4.3
• [new tag] v3.5.0 -> v3.5.0
• [new tag] v3.5.1 -> v3.5.1
• [new tag] v3.5.2 -> v3.5.2
• [new tag] v3.5.3 -> v3.5.3
• [new tag] v3.6.0 -> v3.6.0
• [new tag] v3.7.0 -> v3.7.0
• [new tag] v3.7.1 -> v3.7.1
• [new tag] v3.7.2 -> v3.7.2
• [new tag] v3.8.0 -> v3.8.0
• [new tag] v3.8.1 -> v3.8.1
• [new tag] v3.9.0 -> v3.9.0
• [new tag] v4.0.0-rc1 -> v4.0.0-rc1
  fatal: ambiguous argument 'master..HEAD': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git [...] -- [...]'
  History:

---

Merge 158d9c076736eb34fdb6820a61ff9b2ac2379024 into 394516ced4e6ce5e5fa6014a3ba80ebcd895adeb

Setting rc pre-tag v3.33.0-rc.15 - With pre-tag v3.32.4-rc.0
EVENT: creating local tag v3.32.4-rc.0
Updated tag 'v3.32.4-rc.0' (was a098e4941)
EVENT: pushing tag v3.32.4-rc.0 to origin
2023-07-17T14:51:33Z: **pushing tag v3.32.4-rc.0 to repo /
"message": "Reference already exists",
"documentation_url": "https://docs.github.com/rest/reference/git#create-a-reference"
}`

On first run, the tag is properly created: v3.32.4-rc.0, because it should grab the latest non-rc tag (3.32.3) and bump it. On subsequent runs, it wants to do the same.
Another odd behaviour, is that the part "Setting rc pre-tag" is grabbing the latest RC tag", and "With pre-tag" grabs the correct one.

Thanks in advance

[sbe-arg]

Without seeing the runner logs I can only guess.
1- the tag list order is not working. as u have .33 then .4
[new tag] v3.33.0-rc.9 -> v3.33.0-rc.9
[new tag] v3.4.0 -> v3.4.0
2- using rc1 without rc1.x is not semver compatible? did you use manual tagging or how did u endup with rc1?

One way to try the sort order is fork, revert this and test your fork https://github.com/anothrNick/github-tag-action/pull/272/files

[sbe-arg]

If you can share more details of your release and tagging strategy would help understand what tags are manual or automated in the committer history

[gaspo53]

Hi, thanks for getting back. I'm gonna add my configuration (GH action yaml), and paste some logging. I've "fixed" this by selecting a different prerelease prefic for release/ and a different one for hotfix/ branches. But seems like the problem will show up again at some point.
create-release.yml.zip
logs_6907.zip

[SC4RECOIN]

I just got the same issue with a straight forward tag bump
Bumping tag v0.0.224 - New tag v0.0.225

haven't had any issues before

[sbe-arg]

If you can test as suggested in the previous responses to fork and revert the pr then confirm we can do something about.

I have not seen this but seems the pattern occurs when there are large amounts of tags in the tepo.