Releases are deleted when mirror repository is synchronized

[kotovalexarian]

Description

By some reason the created releases are deleted when mirror repository is synchronized even when the tags have not been recreated.

Steps

1. Sign-in to Gitea
2. Click "+"
3. Click "New Migration"
4. Click "GitHub"
5. Put https://github.com/tailix/libkernaux in the field "Migrate / Clone From URL"
6. Check "This repository will be a mirror"
7. Click the button "Create repository"
8. Click "7 tags" in the bar (the number may be different)
9. Click "New release" on tag "v0.6.1"
10. Put foobar in the field "Title"
11. Click "Publish release"
12. Click on the tab "Settings"
13. Click the button "Synchronize Now"
14. Wait a few (2-5) minutes
15. Refresh the page

Expected

You should see the label "Releases [1]" (the number as a badge) among the tabs.

Got

You see the label "Releases" (without a number) among the tabs.

---

Gitea Version

1.17.3 (self-hosted), 1.19.0+dev-166-g0a85537c7 (try.gitea.io)

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.37.2

Operating System

Ubuntu 22.10

How are you running Gitea?

https://try.gitea.io & self-hosted

Database

PostgreSQL

[lunny]

Hm, maybe we should not allow to create release on a mirror repository?

[kotovalexarian]

Why not keep them on sync?

[iarp]

When setting up a migration from github and selecting the mirroring option, this disables the ability to sync labels, issues, pull requests, releases, milestones. Why would those be touched anyways during a sync when they're not configurable?

I just setup a script to do the mirroring of releases and their assets on a whole bunch of repos only to find everything gone the next day. The attachments still exist in the attachments directory but are no longer associated with any release.

[dboreham]

Also interested in addressing this problem which arises when you use the new CI features in Gitea on a mirrored repository, with CI publishing local releases.

[mrexodia]

Any pointers where to start fixing this in the code?

[lunny]

My point is to prevent users to create releases on a mirror repository currently.
The second method is to not delete releases when syncing tags.

[dboreham]

Please don't prevent release creation on a mirror -- this is how we test/debug our CI processes.

[lunny]

Please don't prevent release creation on a mirror -- this is how we test/debug our CI processes.

OK. Then you would like the second option. But how should Gitea handle when remote tags are deleted from your view point?

[dboreham]

Do you mean local tags?

[lunny]

Do you mean local tags?

I mean as a mirror repository, if the source repository in the remote deleted some tags, when syncing the mirror repository, whether Gitea need to delete the release after the tags deleted?

[mrexodia]

I would suggest to handle it the same as GitHub does. I think if you delete a tag for a release that release gets deleted or converted to draft (not 100% sure). Deleting the release in all cases is undesirable for me.

In my mirror structure I want to manually (with the API) re-create the releases and mirror the binaries too.

[dboreham]

Do you mean local tags?

I mean as a mirror repository, if the source repository in the remote deleted some tags, when syncing the mirror repository, whether Gitea need to delete the release after the tags deleted?

Not sure I care much about tags being deleted in the source repo since I'd never do that. I thought this problem was about this:

1. Release created in mirror repo -- a release has a 1:1 relationship with a tag, implying that a tag must be created in the mirror in order to create a release there.
2. Now sync from the source repo.
3. The mirror is supposed to be read-only, but in step 1 we create a tag locally, hence it is not read-only.
4. What to do about that? Delete the locally created tags, so the repo matches the source? But that means deleting the release.