Tags in UI should be purely git-based

[silverwind]

Feature Description

See discussion starting with #23243 (comment).

I'd like UI tags to be a pure snapshot of all tags in git, e.g. a combination of git tag and git show <tag>. Gitea seems to have some weird concept where a tag is "synced" into the database and as seen in that PR, that sync apparently misses some tags which show empty despite git show <tag> showing all metadata of the tag like:

• Tag name
• Tag tagger
• Tag date
• Tag message
• Tag signature

All this info is in git and does not need to be in the Gitea database.

Releases are a distinct concept from tags and have no relation to them except that a release can optionally point to a tag.

If it helps performance, tag data could be cached in redis etc, but care must be taken so that cache is properly invalidated.

[delvh]

Funny: Isn't there even the opposite issue somewhere here as well, where (I think) @lunny advocates for the opposite, even more database syncing?

But yeah, I'm also not a fan of caching tags like that, that simply leads to errors for a minimal performance gain…

[lunny]

I think reading tags from the database will help to resolve the problems listed here.

1. Performance: Some repositories have many tags, we need pagination. The current pagination actually loads all tags into the memory. Some open-source projects have over 1K tags.
2. Sort: Sometimes, we need to sort tags by oldest or newest, sometimes we need to sort by versions. And sorted results may also need pagination.
3. Filter & Search: With a keyword of the tag name, tag message, tagger and etc. to find the tags.

[silverwind]

These are valid use cases I guess, but how can it be that the database store goes out of sync with git like seen in #23243 (comment)? Are force-pushes a problem?

[lunny]

These are valid use cases I guess, but how can it be that the database store goes out of sync with git like seen in #23243 (comment)? Are force-pushes a problem?

I think there are maybe some bugs, we just need to fix the bugs. Any push will trigger a new Tag sync checking with the function PushUpdateAddDeleteTags, and if this function failed, git client should receive failure information. There is also a subcommand of ./gitea admin repo-sync-releases to execute a manual sync.

[lafriks]

They are synced on push using gitea hook and I have not seen them going out of sync for years imho because if hook is not working than also access control is not working and many other things

[silverwind]

I think there are maybe some bugs, we just need to fix the bugs. Any push will trigger a new Tag sync checking with the function PushUpdateAddDeleteTags, and if this function failed, git client should receive failure information. There is also a subcommand of ./gitea admin repo-sync-releases to execute a manual sync.

I guess then we may have a undetected bug in the linked case.

I'll close the issue. I see the necessity to have tags in the DB for the mentioned performance reasons.