setuptools incorrectly picks tag between multiple lightweight tags (github release)

[ssbarnea]

trafficstars

Assuming the current comment has multiple tags, setuptools only picks the first one, when it would be better to pick that last one instead.

Multiple tags on same commit are not uncommon and they can naturally occur on:

• need to retrigger release pipeline after a networking issue (usually incrementing tag name)
• transforming a pre-release into a release, like 1.0rc2 -> 1.0 (apparently this case works fine, probably because available tags are listed alphabetically before picking one?)

$ git tag --points-at HEAD
0.1a2
0.1a3
0.1a4

In this case setuptools will always pick 0.1a2 regardless how many additional incremental tags are added. This is quite problematic if you have a release pipeline that does not allow overriding versions.

I know that pypi does have an option to ignore existing packages on upload but using it would be a very risky practice.

At this moment, the only workaround I seen for this issue is to add extra commits and avoid having multiple tags on the same commit.

In context with use of GitHub release process, it can easily happen for a specific commit to endup with multiple tags. A simple edit of a release tag name on the web interface would create a new tag, for the same commit, but the triggered pipelines will end-up trying to release the old tag instead of the current one.

After playing a little bit more with git tag listing I was able to identify that order confusion happens only with lightweight tags.

The really bad part is that github seems to generate only lightweight tags and that we cannot prevent users from creating light tags, so the chance of ending up with multiple light tags is real.

[webknjaz]

• need to retrigger release pipeline after a networking issue (usually incrementing tag name)

In such a case I usually remove the old tag first (well, when the publish didn't go through...)

After playing a little bit more with git tag listing I was able to identify that order confusion happens only with lightweight tags.

How so? I'd expect that ordering the output could help...

[webknjaz]

@ssbarnea does git tag --sort -v:tag --points-at HEAD fix the order?

[webknjaz]

Is it because of git-describe @ https://github.com/pypa/setuptools_scm/blob/b845168/src/setuptools_scm/git.py#L16? The docs say that with --tags it should be fine:

--tags Instead of using only the annotated tags, use any tag found in refs/tags namespace. This option enables matching a lightweight (non-annotated) tag.

[RonnyPfannschmidt]

Currently we rely on git describe,

Im open to create a graph based utility that could be used against the github api as well,

But I don't have any bandwidth to plan anything soon

[ssbarnea]

I do still have other issues with GHA and I am aware that this issue is more on github-garden than setuptools-scm, but lets keep it open for a while until document a suitable workaround, especially as GHA are becoming more and more popular.

I personally stopped pushing tags from my machine for security concerns and almost always use the web interface to create them.

@webknjaz I am afraid that for lightweight tags there is no way to make git itself sort them the way we want, because alphabetical ordering is not good (especially when you switch from pre-release to release). The only way to make it work would be if we instantiate all tags as Versions and sort them ourselves, git has no knowledge of the order or the logic for sorting them.

I am wondering if adding a fail-safe guard that fails the run when multiple ambiguous (light) tags are detected on same commit. Maybe a message like "Dude, we found 3 light tags on the same commit and we don't want to make a guess that could produce a bad release version. Remove old ones and try again." could be seen as constructive.

[Julian]

This issue bites me every time I do an alpha release :/ -- obviously I understand deprioritizing it or waiting for someone like me to get unlazy and PR it, but for the record:

The only way to make it work would be if we instantiate all tags as Versions and sort them ourselves, git has no knowledge of the order or the logic for sorting them.

I have done this previously using my own internal tool prior to relying on setuptools-scm and it worked well for my own use cases at least.

adding a fail-safe guard that fails the run when multiple ambiguous (light) tags are detected on same commit

This might be nice, but wouldn't help my typical run in with this problem because when v1.2.3a1 is added it runs with just 1 tag, and then when I say "yup good, now tag that v1.2.3" it fails anyways once it tries to upload.

The error message would be perhaps clearer but to me not a huge win really (i.e. not worth the effort in my opinion).

[RonnyPfannschmidt]

@Julian would you be able to share the logic used for that, i'm low-band-width (which is why i'm not touching stuff like this unless its very critical)

anything that helps turn this from something that takes a while to something i can merge and release quickly would give it a better turnaround

[ssbarnea]

It seems that every other months I accidentally make a full release because the I add a tag like v1.0.0a0 and setuptools-scm ends-up releasing 1.0.0. In fact i would find it far better if I would get an error instead of getting a release in those cases, at least it would avoid costly accidents.

Update: Apparently if I create a tag named v1.0.0-alpha on github releases, setuptools will know to create a version 1.0.0a0 from it. The really tricky bit is that on github releases page there are two places where you need to change the version: the release title and the tag name*. In more than 50% of the cases I only updated the title and endup creating a release tag accidentally. As the tag name is less visible is a very common mistake to make. Maybe someone knows a workaround for preventing such human accidents.

[RonnyPfannschmidt]

We'd have to provide a number of reusable actions to sort out the pain

[webknjaz]

FWIW to address this in a stable manner, I explicitly delete all the tags from the current commit (and re-tag for release requests).

[ssbarnea]

Few years later and I endup at the same bug, this time with a little more interesting twist. I have two tags on head v1.2.3 and v1, the second one being a mobile tag that is moved on each release (very common for github actions versioning).

Apparently when setuptools encounters this, it picks the v1 and messes things up.

I think that the trick here might be to add a filter to force it to ignore any tag that does not have a dot in it, if even possible.

[RonnyPfannschmidt]

It's slightly ludicrous that tags are used like branches

The describe command can be updated to include dots in the match pattern

[webknjaz]

+1. I discourage force-pushing tags and use branches like release/v1 in all my actions to clearly communicate the role of a moving pointer.