Github release should create annotated (not lightweight) tags

[psigen]

( Directly copied from the suggestion here: isaacs/github#1916 )

---

@ssbarnea commented on Feb 9:

At this moment creating a release (tag) using releases page does only create a lightweight git tag, which does not contain essential information like time when it was created. This issue created bug like pypa/setuptools_scm#521 as tools are not able to get information about the tags.

I do think that any tag created by github release should be annotated one: git tag -a instead of just git tag, even if the message would be empty or hardcoded, as this would provide the timestamps that are heavily needed.

Take a look at the difference between annotate tags and lightweight ones, the creatordate is not the tagging date, is the date of the commit! Only annotated ones have the taggerdate property.

$ git tag --format='%(creatordate)%09%(refname:strip=2)   %(taggerdate)'                                                                           [10:28:48]
Tue Feb 9 09:48:55 2021 +0000	0.1
Tue Feb 9 09:48:55 2021 +0000	0.1.1
Tue Feb 9 08:55:44 2021 +0000	0.1a0
Tue Feb 9 09:21:49 2021 +0000	0.1a1
Tue Feb 9 09:48:55 2021 +0000	0.1a2
Tue Feb 9 09:48:55 2021 +0000	0.1a3
Tue Feb 9 09:48:55 2021 +0000	0.1a4
Tue Feb 9 10:16:42 2021 +0000	0.1a5   Tue Feb 9 10:16:42 2021 +0000
Tue Feb 9 10:19:46 2021 +0000	0.1a6   Tue Feb 9 10:19:46 2021 +0000
Tue Feb 9 10:25:51 2021 +0000	0.2   Tue Feb 9 10:25:51 2021 +0000
Tue Feb 9 10:25:59 2021 +0000	0.2.1   Tue Feb 9 10:25:59 2021 +0000
Tue Feb 9 09:21:49 2021 +0000	0.3a0

[danielgomezrico]

We do need this, we create releases from the Github UI and our CI tool which uses git describe --tags --match=* from fastlane semantic_release lane to get the latest changelog automatically.

If we have this, we can do it pretty easily

[wesleyboar]

Similarly, I want git describe --always to give a useful identifier, but with unannotated tags, two problems can happen:

• if latest tag is lightweight, identifier references last version with annotated tag (plus count of many commits since)
• if all tags are lightweight, it only returns a commit hash

The placeholder solution [I use] is to run my script manually [after each release].

[mpldr]

Just to quote the git-tag manpage:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default.

So it would be great to have GitHub work "as intended"

[msharov]

I would have thought that a release is a sufficiently important event as to warrant a signed tag. Is there a reason you can't sign the release tags? For my projects, I always do that first and then convert it to the GitHub release on the web UI. This makes git describe work and marks the release as verified. What's not to like?

[mpldr]

It's actually a feature of git. As seen in my comment: annotated tags are supposed to be used for releases and you can sign them just fine. But to my knowledge you can't create them using GitHub's UI

[ErikReider]

This would really make my workflow a lot easier

[nomennescio]

More importantly, lightweight tags are NOT copied into forks! Whereas annotated tags will. This should be changed as soon as possible, and is trivial to do.

[numbsafari]

I'd just like to add that it's not at all necessary for GH to try and include any of the release notes as part of the annotated tag. We really just need the tag to be annotated so that it is exposed via, e.g., git describe. Also, having the release tag be signed would be hugely helpful for compliance.

[HenryNguyen5]

Just ran into this recently. It makes Github's API for creating signed objects inconsistent since you can create signed commits via the API, but not annotated tags. This makes it impossible to have signed annotated tags when using Github App tokens, which are much more safe than using machine users due to being able to provision ephemeral granular API tokens.

If we can get signed annotated tags, that would open up more automation possibilities using safer methods of authentication with Github's API

Related: https://github.com/orgs/community/discussions/24664#discussioncomment-5084236

[karlw-bjss]

This needs to be done. Lightweight tags should not be used for releases. This is, effectively, a bug rather than a feature request.

[igiona]

Tools like Yoct/bitbake make heavily use of the annotation.
Without annotation being used in GitHub makes the release process over GitHub UI almost meaningless, at least for repos which are used in Yocto projects 😢

[mr-git]

UPDATE: I was wrong, sorry! details in my next comment

---

fix for this issue broke ability to call workflows by Release tag - https://github.com/orgs/community/discussions/48693#discussioncomment-6132963

https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow - using @{ref} doesn't work any more

[nomennescio]

When and how was this fixed?

[mr-git]

honestly, I am not sure.

In my case, I got tripped by inability to reuse workflow from internal repo in public repo, and error was not expressive enough. I assumed that issue was with release tag which lead me to this discussion, but I was wrong - I noticed annotation on "release", but the tag doesn't have them.

sorry, my bad.

[psigen]

@mr-git Could you edit your top-level comment to clarify that the tag actually doesn't have an annotation? (like an "Update: [...]" edit) That will help others avoid confusion if they read this thread in the future.