[sergeyfast]

The v0.1.6 release run failed. The tag sits on 8f9012d, the same
commit as v0.1.6-rc.2 — the normal case when a release candidate
needs no further fixes — and goreleaser rebuilt the rc instead:

• using tags   previous=v0.1.5 current=v0.1.6-rc.2
⨯ release failed: failed to upload topsrv_0.1.6-rc.2_linux_amd64.tar.gz:
  422 Validation Failed [{Resource:ReleaseAsset Field:name Code:already_exists}]

Left to itself goreleaser picks among the tags pointing at HEAD with
--sort=-version:refname, and git's versionsort ranks the rc higher
unless versionsort.suffix is configured — it reads -rc.2 as more
refname, not as a semver prerelease:

$ git tag --points-at 8f9012d --sort=-version:refname
v0.1.6-rc.2
v0.1.6

So every artifact carried the rc version, and the upload then died on
the rc's own release, which already holds those asset names since
8 September. That release is unharmed — the 422 is what protected it —
and no v0.1.6 release was created.

GORELEASER_CURRENT_TAG pins the build to github.ref_name, the tag
the workflow was triggered by. Setting versionsort.suffix instead
would work too, but it fixes the ordering by enumerating suffixes we
happen to use today; taking the tag from the trigger has nothing to
guess.

The fix has to land in master before v0.1.6 can ship: CI reads the
workflow from the tagged ref, so the tag must point at a commit that
carries it. Once this merges I'll move v0.1.6 onto the new master
HEAD and push — the current tag has no release behind it, so nothing
downstream can have consumed it.