All releases lost upon upgrading from Gogs to Gitea-1.3.2

[strk]

• Gitea version (or commit ref):1.3.2
• Git version: 1.7.10
• Operating system: GNU/Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant (cannot test an upgrade there)

Description

Gogs used to show every tag in the Releases page, upon upgrade all those entries in Releases are gone. I've tried that removing all remote tags and re-pushing them is effective as a work-around, but it is crazy to do this for each and every repository we host.

@lafriks mentioned this synchronization should have happened at migration time but evidently it did not. How to fix now ? I think there should be an admin task to resynchronize those releases or we're stuck forever with this problem.

The problem may or may not be related to git version being < 1.8 - see #1133 (from #1133 (comment))

[lafriks]

API method could be added as I don't see where could it be added in admin interface

[strk]

I'm doing an ./gitea admin repo-sync-releases-with-tags command. Want to help with that ? I dont' see how am I supposed to get the engine from model, although admin calls models.SetEngine() I don't see any models.GetEngine() function..

[lunny]

That command should be help and seems it's easy to implementation.

[lunny]

@strk which version was your Gogs? Maybe you lost some migrations?

[lafriks]

You need to call models function that does not require engine or create one

[strk]

Gogs-0.9.99.0903, with database at version 14. The "release" table, present, was empty. Model functions are not what the migration (v39.go) calls. The migration does make use of `x` (the engine) to get the list of repositories to scan/sync.

[strk]

Actually, I went looking logs and found the probable cause of loosing all those releases:

2017/10/18 13:27:11 [I] Migration: add tags to releases and sync existing repositories 2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git ... 2017/10/18 13:27:12 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any of the parent directories): .git 2017/10/18 13:27:12 [I] Migration: remove duplicate unit types

There seem to be some problem with the repository paths.

[strk]

Working more on the PR adding an admin command to re-sync I found more problems: the function used by the migration supposed to synchronize repo tags with releases does not really work. Do you remember who changed the way releases were handled ?

[ethantkoenig]

@strk I believe it was @lafriks: #2459

[strk]

@lafriks can you check if things work for you ? Easy test:

1. Create test repository
2. Clone test repository locally (via commandline, from filesystem, not Gitea)
3. Add a tag, push the tag locally (via commandline, to filesystem, not Gitea)
4. Verify release tab does not show new tag
5. Run the ./gitea admin repo-sync-releases command, check output

For me, the final step does not add any new release record in the database, while I believe your migration 42 (from which code in this PR is taken) was meant to do exactly that ?

[lafriks]

@ethantkoenig @strk I fixed so that tags are actually displayed in release page and created that sync function but I was not one who broke displaying them in release page as before my PR tags would not be displayed in release page at all. I will try to reproduce your steps

[strk]

I fixed so that tags are actually displayed in release page
before my PR tags would not be displayed in release page at all

I don't understand the above two statements. What did you fix ?
What do you expect to see now in releases page ?
Do you have a reference to a ticket describing the problem you (tried to) fix ?

[strk]

self-answering the last question: previous ticket was #2154

[lafriks]

@strk can this be closed than?

[strk]

I don't think so, we should try to reproduce the occurrence and make the migration more tolerant. I was coming from Gogs 0.9.99.0903

[stale]

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.

[lunny]

I'll close this one. Please feel free to reopen it.