goreleaser attempt to release an existing tag and fail

[Lyndon-Li]

What happened?

Due to the change in this PR, when there is a pre-release, the command git tag --points-at HEAD --sort -version:refname generates below result, from which goreleaser picks v1.10.0-rc.2 to create the release. It is expected to pick v1.10.0, and v1.10.0-rc.2 has been released:

git tag --points-at HEAD  --sort -version:refname
v1.10.0-rc.2
v1.10.0

How can we reproduce this?

Release one pre-release, for example, v1.10.0-rc.2
Don't make any new commit so as to keep the HEAD unchanged
Create a GA release, for example, v1.10.0
[Result] The second release fails

goreleaser version

1.13.1

GoReleaser Check

• goreleaser check shows no errors

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[caarlos0]

hmm, will see what I can do... as a workaround you can set GORELEASER_CURRENT_TAG environment variable to the version you want for this release...

[Lyndon-Li]

Thanks, the workaround should work, meanwhile please help to check if this problem can be fixed in any of the new releases.

[caarlos0]

it might not be possible to fix.

[caarlos0]

explaining: if I revert that commit, it'll break somewhere else... and it seems like git cant sort by multiple fields and does not take the semantic version fields into consideration (it seems).

what we might be able to do is add a config for the sorting, so its the user responsibility.

But its more of a feature than a bug...

[Lyndon-Li]

This command git tag --points-at HEAD --sort=v:refname could return the correct result in this scenario, but not sure if it meets others requirements.

[caarlos0]

nope, that would return v0.0.1 instead of v0.0.2, for example...

[caarlos0]

another idea would be to use git config --get tag.sort if set, defaulting to the current behavior... so users could set it per repo... but I guess having it in the yaml is likely better. either way, will look into it tomorrow.

[caarlos0]

please check #3611