-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest tag is not used for versioning when multiple tags exist #13
Labels
bug
Something isn't working
Comments
rpanderson
added a commit
that referenced
this issue
May 17, 2020
Resolved by 9f6bbd6 (tagged as |
See actions/checkout#258. |
I guess that will let us change to something like: - name: Checkout
uses: actions/checkout@v<next-version>
with:
fetch-depth: 0
- name: Ignore HEAD tags
if: github.event.ref_type != 'tag'
run: git tag -d $(git tag --points-at HEAD) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem
v0.3.1rc2
and push this tag.v0.3.1
and push.0.3.1rc2
.Example: https://github.com/rpanderson/workflow-sandbox/runs/682565320 (on: create tag v0.3.1).
What's happening here?
setuptools_scm
ran on this shallow checkout, everything would be fine of course (there's only one tag).Same commit, different tag. Reproducing this locally, one can inspect two types of tag ordering native to git,
creatordate
andcommitterdate
.The earlier tag (v0.3.1rc2) takes precedence. Presumably because it got 'created' in the local checkout more recently, i.e. (simple) tag creation is a local concept. But from some cursory testing, it's how setuptools_scm appears to be getting the most recent tag.
The
committerdate
ordering, on the other hand, returns the correct ordering:Q: Is this the same for annotated tags?
Solutions
committerdate
.Option 2 seems the best here, as the unshallow is unnecessary when the workflow is triggered off tag creation events.
The state of actions/checkout
Tagging seems to be a hot topic there, right now!
fetch-depth: 1
and not cloning tags are dangerous defaults actions/checkout#217The solution/conclusions here may change if any of these are resolved.
How does versioneer deal with this scenario?
Since 2011, warner/python-versioneer has dealt with multiple tags. See, e.g. python-versioneer/python-versioneer@0a78af3. This apparently just uses
sorted()
on the refs which seems to suffice, although I have no experience with it on Github Actions.This doesn't work however for the example atop python-versioneer/python-versioneer#79, i.e. 1.0.0 is chosen over 1.0.1 (although surely this would be a case of erroneous tagging and one of these could/should be deleted).
Curiously, @warner points out in a reply to this PR:
Yet in this example, v1.0 would be used, by the very code they committed 4 years prior (above). Maybe I'm missing something. This is the same code kicking around a lot of projects using versioneer, including those who've vendored it. And it seems to work for the case of release candidate not being promoted over release.
The text was updated successfully, but these errors were encountered: