Show tag messages on releases page #4108

Closed
opened 2025-11-02 05:38:25 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @silverwind on GitHub (Oct 13, 2019).

Tag messages are currently not being displayed on the UI. Comparison to GH:

https://github.com/silverwind/symlink-test/releases

https://try.gitea.io/silverwind/symlink-test/releases

Originally created by @silverwind on GitHub (Oct 13, 2019). Tag messages are currently not being displayed on the UI. Comparison to GH: https://github.com/silverwind/symlink-test/releases <img width="421" src="https://user-images.githubusercontent.com/115237/66719396-68a32600-edef-11e9-8113-ae3166e10896.png"> https://try.gitea.io/silverwind/symlink-test/releases <img width="505" src="https://user-images.githubusercontent.com/115237/66719397-693bbc80-edef-11e9-8563-419f70995886.png">
GiteaMirror added the type/featureissue/confirmed labels 2025-11-02 05:38:25 -06:00
Author
Owner

@zeripath commented on GitHub (Oct 13, 2019):

It appears that for annotated tags we don't store the SHA1 to the tag object but rather the commit SHA1. We don't store the commit message in the db either.

So there are three issues:

  1. For annotated tags we need to store the annotated tag SHA1 in future. Decide whether to store this in addition or instead of the commit. Probably in addition? Edit: I think instead might be better actually.
  2. We need go back over our tags and store the annotated tag SHA1 - that's a migration task. Edit: I'm assuming here that the tag name should match with that in the refs/tags otherwise it might not be possible.
  3. We need to decide which message to show: a) The commit message b) the annotated tag message or c) both. Edit: it appears to be annotated if available otherwise commit.

We would need to use the same processing we use on commit messages elsewhere. Including demonstrating if the object is signed. Edit: and author etc.

We should decide if we want to store the commit message/tag message in the db in the notes field - on a large repo that could be slow but equally we're probably going to want to interpret the tag and commit properly. Edit: I suspect it's best not to store this stuff in the db. We could for example use the db fields to provide extra context through allowing owners to add extra comments etc.

@zeripath commented on GitHub (Oct 13, 2019): It appears that for annotated tags we don't store the SHA1 to the tag object but rather the commit SHA1. We don't store the commit message in the db either. So there are three issues: 1. For annotated tags we need to store the annotated tag SHA1 in future. Decide whether to store this in addition or instead of the commit. Probably in addition? Edit: I think instead might be better actually. 2. We need go back over our tags and store the annotated tag SHA1 - that's a migration task. Edit: I'm assuming here that the tag name should match with that in the refs/tags otherwise it might not be possible. 3. We need to decide which message to show: a) The commit message b) the annotated tag message or c) both. Edit: it appears to be annotated if available otherwise commit. We would need to use the same processing we use on commit messages elsewhere. Including demonstrating if the object is signed. Edit: and author etc. We should decide if we want to store the commit message/tag message in the db in the notes field - on a large repo that could be slow but equally we're probably going to want to interpret the tag and commit properly. Edit: I suspect it's best not to store this stuff in the db. We could for example use the db fields to provide extra context through allowing owners to add extra comments etc.
Author
Owner

@silverwind commented on GitHub (Oct 13, 2019):

Just pushed 0.0.4-lw which is a lightweight tag to my testing repo to see what GH does. In summary:

  • For annotated tags they show tag name, tag message, gpg signature of the tag, link to commit.
  • For lightweight tags they show commit name, commit message, gpg signature of the commit, link to commit.

I don't think the commit message in the tag is of much value, assuming it's a copy of the commit it links to so a link to the commit should be fine.

Edit: small correction, commits do not have names, only tags do.

@silverwind commented on GitHub (Oct 13, 2019): Just pushed `0.0.4-lw` which is a lightweight tag to my testing repo to see what GH does. In summary: - For annotated tags they show tag name, tag message, gpg signature of the tag, link to commit. - For lightweight tags they show ~~commit name~~, commit message, gpg signature of the commit, link to commit. I don't think the commit message in the tag is of much value, assuming it's a copy of the commit it links to so a link to the commit should be fine. Edit: small correction, commits do not have names, only tags do.
Author
Owner

@stale[bot] commented on GitHub (Dec 12, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Dec 12, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
Author
Owner

@silverwind commented on GitHub (Nov 7, 2020):

This was fixed recently, minus the tags on the releases list.

@silverwind commented on GitHub (Nov 7, 2020): This was fixed recently, minus the tags on the releases list.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4108